yaml锚点与合并键（&+
权限配置冗余，本质是重复定义相同字段（如 environment、volumes、cap_add 等）导致维护困难、易出错。YAML 的 Merge 合并法 不是 Docker Compose 原生字段，而是依赖 YAML 语言级特性（& 锚点 + 合并键）实现的“软继承”，它比 <code>extends 更灵活——支持同文件内细粒度复用与局部覆盖，且不触发跨文件加载限制。
用锚点+合并键统一权限模板
把通用权限项（如特权模式、能力集、挂载路径）抽成锚点，供多个服务引用：
- 定义一次：
privileged: true、cap_add: ["NET_ADMIN", "SYS_TIME"]、volumes: ["./config:/etc/app:ro"] - 所有需该权限的服务用
引入，无需逐条重写 - 若某服务需额外加一个 volume，直接在自身配置里追加，不影响其他服务
合并行为要盯住类型差异
不是所有字段都“自动叠加”。YAML Merge 只控制结构合并逻辑，而 Docker Compose 对字段的实际处理仍遵循其内置规则：
-
environment：键值对合并，后定义的 key 覆盖前同名 key -
volumes和ports：列表追加（Merge 本身不干预，但 Compose 层会保留全部条目） -
image或command：完全被当前服务定义覆盖（无合并），所以别指望用 Merge 改镜像
避开循环引用和作用域陷阱
锚点必须在引用前定义，且不能跨 YAML 文件隐式生效（docker compose -f 多文件时，每个文件独立解析锚点）：
- 把权限锚点集中放在文件顶部或专用
defaults:区块，避免散落难追踪 - 不要让服务 A 引用 B，B 又间接引用 A（例如通过嵌套别名），YAML 解析器会报错
- 若需跨文件复用，改用
extends（支持file:指定外部文件），而非依赖锚点
对比 extends：什么时候选 Merge？
两者解决的是不同层级的冗余：
- 用
extends：当你有一整套服务骨架（含 image、networks、deploy 等），要在 dev/prod 中复用并整体覆盖——适合环境级复用 - 用
Merge（锚点+）：当你只想复用部分字段（尤其是权限类、日志类、健康检查类），且这些字段分散在多个服务中——适合字段级复用 - 混合使用更常见：用
extends继承基础服务，再用注入统一权限策略
