共享库解决什么
没有共享层时，每个团队都会自己实现「安装并配置某中间件」这类通用做法，结果是同一件事出现多个版本，安全修复需要重复落地，质量参差。共享库把这类能力集中到一处维护，使用者以引用方式获取，修复一次即全部受益。代价是共享层成为依赖：它的变更会影响所有引用方，因此需要版本、变更说明与兼容策略。
基本信息
| 共享内容 | 通用角色、模块封装、基础模板、校验与巡检脚本 |
|---|---|
| 使用方式 | 引用指定版本，而非复制内容 |
| 准入标准 | 被两个以上团队实际使用、有明确参数契约 |
| 维护要求 | 有责任人、有版本、有变更说明 |
建设要点
- 先试后用：先在单个团队验证稳定，再提升为共享能力。
- 参数契约清晰：输入输出明确定义，避免使用者需要读实现才能用。
- 版本可见：使用者引用具体版本，升级由使用方主动进行。
- 变更留说明：破坏性变更需提前公告并给出迁移方式。
- 组合而非膨胀：共享能力宜小而稳定，复杂流程由使用方在编排层组合。
- 质量门禁：共享内容需通过统一检查（语法、命名、幂等性）才能合并。
共享层管理事项
| 事项 | 要求 | 缺失后果 |
|---|---|---|
| 准入 | 有多个使用方且已验证 | 共享层充斥一次性做法 |
| 参数契约 | 输入输出与默认值明确 | 使用者必须读源码才能调用 |
| 版本管理 | 引用具体版本 | 共享变更直接破坏使用方 |
| 变更公告 | 破坏性变更提前说明 | 升级时集中出问题 |
| 责任人 | 明确维护者与响应方式 | 问题无人修复长期存在 |
| 质量门禁 | 统一检查通过才合并 | 共享内容质量参差 |
共享库的成功指标是「被引用次数」与「使用者的改动成本」，而不是收录了多少能力。收录多但无人使用的共享层只会增加维护负担。
共享能力的破坏性变更影响面很大：直接修改而非新版本发布时，所有引用方会在同一次执行中受影响，回退也需要全量同步回退。