Service Mesh 要求通信完全经由 Sidecar 透明拦截，禁止业务代码调用 start() 等生命周期方法，否则会破坏解耦、绕过策略、失效安全与追踪、引发状态冲突、削弱统一治理；应使用标准客户端和服务发现地址，策略交由控制平面统一配置。

因为 Service Mesh 的核心价值之一，就是把通信治理逻辑（如重试、超时、熔断、链路追踪）从业务代码中彻底剥离。如果允许业务代码主动调用 start() 类方法，等于重新打开了“手动介入网络生命周期”的后门，直接破坏这一解耦原则。

破坏透明拦截机制

Service Mesh 依赖 Sidecar（如 Envoy）以无侵入方式拦截所有出/入站流量。一旦业务代码绕过代理、自行启动连接或管理客户端生命周期（比如调用 HTTP 客户端的 start()、init() 或自建连接池），就可能：

• 跳过 Sidecar 的流量控制策略（如超时设置、重试次数限制）
• 绕过 mTLS 加密与身份校验，导致安全策略失效
• 使请求丢失 traceID 或 span 上下文，造成链路追踪断裂

引发资源与状态管理冲突

业务层若自主管理连接生命周期，容易与 Mesh 数据平面产生竞争：

• Sidecar 默认按连接复用、健康探测、优雅关闭等统一策略管理连接；业务代码重复做这些事，会干扰连接池稳定性
• 例如：业务在未通知 Sidecar 的情况下关闭连接，可能导致 Sidecar 缓存了已失效的连接句柄，后续请求失败
• 多线程环境下，start() 调用若非幂等或未同步，可能触发重复初始化、内存泄漏或竞态异常

削弱统一治理能力

大厂依赖控制平面（如 Istio、Linkerd）集中下发策略。当业务代码可以任意启动通信组件时：

• 限流规则无法覆盖所有出口路径（部分请求走“直连”，不经过策略引擎）
• 故障注入、灰度路由、金丝雀发布等能力对这部分流量完全失效
• 监控指标口径不一致——Sidecar 统计的“出向请求数”与业务实际发出数出现偏差，影响容量评估与告警准确性

替代方案更可靠且符合云原生约定

不是不让通信发生，而是要求通信必须走标准、受控的路径：

• 使用标准 HTTP/gRPC 客户端（如 OkHttp、gRPC-Java），不调用底层生命周期方法，由运行时或 SDK 自动适配 Mesh 环境
• 通过服务发现地址（如 http://user-service.default.svc.cluster.local）发起调用，确保流量必经 Sidecar
• 配置类行为（如超时、重试）统一通过 CRD（如 Istio 的 DestinationRule）定义，而非硬编码在业务里