何时该用现成标准框架、何时该自研规范：以OSGI vs 自定义插件规范为例

面对”插件化”这个已有成熟标准（如OSGI）覆盖的问题域，U系统的引擎却没有直接采用OSGI，而是实现了一套自定义规范，这个决策提供了一个判断”什么时候该复用现成标准框架、什么时候该自己造一套更简单的东西”的具体范例：一是OSGI主要定位在服务的注册、发现、隔离和调用上，但U系统的服务发现和治理已经由成熟的远程RPC框架承担，引擎自身的代码是可控的，只需要进程内调用和Spring级别的依赖管理，OSGI在这个维度上提供的能力是重复建设、用不上；二是OSGI几乎没有交互界面相关的功能，而解析插件里的交互DSL、处理界面逻辑对U系统而言恰恰是核心需求，标准框架在真正需要的地方反而是空白；三是OSGI用Bundle方式发布，虽然灵活但U系统根本不需要那么灵活的Import/Export机制，写死引擎提供的接口反而降低了使用成本，直接上传XML配置也比构建和发布Bundle更简单。这三点共同指向一条决策原则：选不选现成标准，不该只看”它是不是业界公认的方案”，而要具体比对自己的真实需求和标准框架的能力边界——如果标准框架的核心能力大部分用不上（治理已被别的组件覆盖），而自己真正需要的能力标准框架又不提供（交互DSL），并且标准框架的灵活性对自己而言是不必要的复杂度（Bundle机制），那么自己实现一套更贴合、更简单的方案往往是更优选择，”造轮子”本身不是问题，盲目复用不匹配的标准框架才是问题。