用途：Sidecar 模式将辅助服务与主应用一起部署并共享生命周期，用于在不修改主应用代码的情况下处理日志、监控、安全等横切关注点。在 Kubernetes 中，sidecar 与主容器运行在同一 Pod、共享网络命名空间，通过 localhost 通信；在 Docker Compose 中，sidecar 与主服务共享 Docker 网络，通过服务名通信。
主要能力与常见配置：服务网格（Envoy/Istio）提供服务间 mTLS、熔断、负载均衡与可观测性；日志聚合（Fluentd/Filebeat）采集应用日志并发送到 Elasticsearch/Splunk；认证代理（oauth2-proxy）拦截 HTTP 请求、校验 JWT/OAuth 后转发；配置监听（Consul/etcd agent）监听配置变更、更新共享卷供应用热重载。
必要用法：必须共享生命周期，sidecar 与主服务一起启动、停止和扩缩；必须网络透明，主服务无需感知 sidecar；每个 sidecar 只负责一个横切关注点，例如 logging-sidecar 只做日志聚合、metrics-sidecar 只做 Prometheus 抓取、auth-proxy-sidecar 只做认证。Kubernetes 中作为同一 Pod spec 的额外容器部署；Docker Compose 中作为 depends_on 服务共享网络部署。
限制与边界：不要把业务逻辑放进 sidecar，它只处理基础设施关注点（日志、指标、TLS、重试）；单体应用应使用中间件而非 sidecar；单一简单服务若开销不合理则不必使用；sidecar 与主应用逻辑紧耦合时也不适用。需注意资源竞争（显式设置资源限制）、启动顺序（用 initContainers 或就绪探针确保 sidecar 先健康）、调试时通过分布式追踪传递关联 ID。
资料另提及 deployment-patterns.md 包含完整 Docker/Kubernetes 示例、服务网格配置与监控设置，但具体内容暂未提供。