Flask 注册 endpoint 冲突后继续启动，新 URL 却调用旧视图

Flask启动时提示 View function mapping is overwriting an existing endpoint function，代码捕获AssertionError后继续启动；结果“注册失败”的新URL居然能访问，而且调用了旧视图。不要把这个异常当作可以忽略的重复提示，应用的路由配置可能已经处于不完整状态。

Flask3.1.3的add_url_rule先把rule加入url_map，再检查endpoint是否已经绑定另一个view_func。后一步失败不会自动撤回前一步。因此，新URL可能已经指向旧endpoint，继续运行就会把请求交给原来的函数。

endpoint与URL路径不是同一个名称

下面是冲突形态的说明，不要在已有应用上重复执行：

app.add_url_rule('/a', endpoint='same', view_func=first)
app.add_url_rule('/b', endpoint='same', view_func=second)

假设first和second是两个不同的视图函数。第二次调用试图让同一个endpoint改绑另一个函数，触发AssertionError；它不是在声明两个正常共享同一视图的URL。

endpoint还参与url_for等反向生成规则。只看URL路径不重复，不能证明endpoint也唯一；装饰器包装函数、动态插件和重复导入都应检查实际传入的函数对象与名称，不能只比较源码中的函数名。

让失败的初始化停止，而不是带错配置服务

去掉忽略这类AssertionError的启动逻辑，修正真正冲突的endpoint或重复注册位置。启动阶段失败后重新创建一份应用对象，并按完整配置注册；不要把已经部分修改的对象继续交给WSGI服务器。

如果两条URL本来就应调用同一个函数，可以按框架支持的方式绑定同一视图；如果代表不同业务，就为它们设置各自的endpoint，并同步已有url_for引用、Blueprint名称和相关测试。不能只给endpoint随机追加后缀，让反向链接悄悄指错地方。

不要在请求处理期间临时移除或重写url_map、view_functions的私有状态。多worker进程可能各自保留不同配置，单独修补一个进程不能保证所有入口一致。路由、扩展和Blueprint应在开始服务前完成设置。

在新的应用实例上核对每条URL的实际视图、方法和反向生成结果，并确认权限装饰器仍属于预期函数。尤其检查曾经注册失败的URL，不能只测试原来的/a仍返回200。异常不再出现只是启动验收的一部分，请求确实落到正确业务与授权范围才算恢复。