Python新增带层数参数的break/continue语法改进的负面影响有哪些？

这个语法设想确实能解决多层嵌套循环跳出的痛点，但负面影响也非常明显，主要包括以下几点：

• 可读性反而下降，维护成本飙升
  当嵌套层数较多、或者循环中间穿插了大量业务逻辑时，读者要准确匹配break 2、break -3这类语句对应的循环层级，必须逐行数嵌套层数，非常容易出错。如果后续代码迭代中新增、删除了某层循环，所有对应位置的break索引值都要同步修改，漏改一个就会产生极难排查的逻辑错误，反而比标志位、封装函数用return跳出的方案更难维护。
• 违背Python核心设计哲学
  Python一直遵循「There should be one-- and preferably only one --obvious way to do it」的设计原则，目前多层跳出的标准实现方案已经非常明确：要么把嵌套逻辑封装为独立函数，满足条件时直接return；要么自定义异常通过try-except捕获跳出。新增多层break语法等于额外新增了多种实现路径，会导致不同项目、不同开发者的代码风格严重不统一，大幅提升团队协作的沟通成本。
• 工具链适配成本极高，且引入新的异常场景
  现有Python的语法解析器、AST处理工具、静态检查工具（pylint、mypy等）、代码格式化工具（black等）都需要做大量改造才能支持这套新语法。此外如果代码中出现break的索引值超过实际嵌套层数的情况（比如只有3层嵌套却写了break -4），无论是设为语法错误还是运行时错误，都会给开发者增加额外的踩坑风险，这类错误也很难通过静态检查100%覆盖。
• 控制流复杂度上升，提升调试难度
  带层级的break本质上是受限的goto语句，会让代码的控制流跳转变得更不直观。调试多层跳转的代码时，很难快速定位当前break到底跳出了哪几层循环，排查问题的效率会远低于用标志位或者return的实现方案。
• 语法一致性要求带来的额外负担
  如果要保持语法一致性，continue关键字也需要同步支持相同的层级索引规则，哪怕这类场景使用率极低，也需要投入大量开发、测试资源完成适配，同时也会给学习者增加额外的记忆负担。

内容的提问来源于stack exchange，提问作者MikeTeX