开闭原则是“对扩展开放、对修改关闭”，核心是不破坏已有逻辑的实现；可通过新增类、接口、注册表或依赖注入实现扩展，而非修改原有代码。
开闭原则不是“不改代码”，而是“不改已有逻辑的实现”
开闭原则（OCP）常被误解为“绝对不能动源码”，其实质是：对扩展开放，对修改关闭——重点在「已有行为逻辑不被破坏」。你完全可以新增文件、新写类、新注册函数，只要老代码调用路径不变、契约（接口/参数/返回值）不变，就算守住 OCP。
最容易踩的坑是强行塞 if-else 或 switch 到原有函数里加新分支，比如在 processOrder() 里加 if type === 'vip' {...}。这看似没动“结构”，但每次加类型都要改它，违反了“修改关闭”。
- 正确做法：把订单处理逻辑抽成策略接口，
OrderProcessor只负责调度，具体实现由VipOrderHandler、NormalOrderHandler等独立类承担 - 关键判断点：改动后，单元测试中所有原有
processOrder()的测试用例是否仍全部通过？如果需要重写或跳过某些断言，说明已破坏封闭性 - 语言差异：TypeScript 可靠接口 + 工厂函数；Python 常用
abc.ABC+ 注册表；Go 用接口+依赖注入，避免直接 new 具体类型
如何识别“该走扩展而不是修改”的信号
不是所有新增需求都适合 OCP，但以下现象出现时，强烈建议停手、重构、再扩展：
- 你在改一个已有函数，只为支持一种新输入类型，而它原本只处理一种 —— 比如
parseJSON(data)突然要兼容parseXML(data) - 你发现要加大量
typeof、instanceof或data.format === 'yaml'分支判断 - 同事在 Code Review 里问：“这个 if 是临时的吗？”——大概率不是临时的，是扩展点缺失的征兆
- CI 测试里某个模块的覆盖率突然掉了一截，因为新加逻辑绕过了原有路径
这时候，与其补丁式修改，不如定义统一入口（如 Parser 接口），让 JSONParser、XMLParser 各自实现，由工厂或配置决定用哪个。
免费 盛世企业网站管理系统(SnSee)系统完全免费使用，无任何功能模块使用限制，在使用过程中如遇到相关问题可以去官方论坛参与讨论。开源 系统Web代码完全开源，在您使用过程中可以根据自已实际情况加以调整或修改，完全可以满足您的需求。强大且灵活 独创的多语言功能，可以直接在后台自由设定语言版本，其语言版本不限数量，可根据自已需要进行任意设置；系统各模块可在后台自由设置及开启；强大且适用的后台管理支
依赖注入和注册表是落地 OCP 最常用的两个杠杆
没有机制支撑，OCP 就是空谈。硬编码 new 实例、全局变量挂处理器、手动改 switch 表，都会让扩展变成高风险操作。
- 用依赖注入：把具体实现作为参数传入，而非在类内部 new ——
new OrderService(new VipOrderHandler())，替换 handler 不用碰OrderService源码 - 用注册表：启动时动态注册处理器，比如
ParserRegistry.register('yaml', new YamlParser())，后续ParserRegistry.get('yaml').parse(...)自动路由，增删格式都不动核心调度逻辑 - 警惕陷阱：注册表本身若用静态变量 + 隐式初始化（如 import 时就执行 register），会导致测试间污染；应显式初始化，或用容器生命周期管理
- 性能提示：注册表查找一般 O(1)，但若用字符串匹配做路由（如正则 or includes），可能引入隐式性能衰减，优先用精确 key 查找
测试覆盖是验证 OCP 是否真被守住的唯一标尺
写完扩展逻辑后，运行原有全部测试。如果失败，要么是契约被破坏（比如新 handler 返回了不同结构），要么是旧路径被意外干扰（比如注册表覆盖了默认实现）。
- 确保每个扩展类都有对应单元测试，但更重要的是：跑一遍老模块的完整测试集，尤其是集成场景（如
processOrder()调用链） - 不要只测“新功能能用”，要测“老功能没变”——比如原来
processOrder({type: 'normal'})返回{status: 'ok'}，现在还得一样 - Mock 依赖时注意粒度：若 mock 掉整个
PaymentService，可能掩盖新 handler 对它的新调用方式；应保留真实协作流，只隔离外部副作用（如网络、DB）
OCP 的复杂点不在概念，而在边界感——什么时候该划新接口，什么时候该复用旧字段，哪些契约一旦定下就不能松动。这些判断没法靠规则穷举，得靠每次改代码时多问一句：“我动的这一行，会让谁的测试崩掉？”
