问题描述 昨天发布系统时，某个 RPC 接口的入参方式从 request parameters 改造为 request body。这个改动方向是对的，但由于接口设计和发布流程未充分考虑兼容性问题，导致 customer 在调用时偶发 400 错误。
根本原因：滚动发布过程中，新旧版本的 customer 和 provider 会同时存在于系统中。如果版本组合处理不当，就会出现新版本 customer 调用旧版本 provider（或相反）的情况，因参数格式不一致而报错。
解决方案 核心思路是让 provider 具备向下兼容能力，保证新旧版本共存期间调用链路不受影响。具体分三步：
Provider 新增新接口，保留旧接口 在 provider 侧新增支持 request body 的新接口，同时保留原有接口不变，两者业务逻辑保持一致，仅入参方式不同。
Customer 切换调用新接口 Customer 代码统一改为调用新接口。
控制发布顺序：先升级 provider，再升级 customer 滚动发布时，先将 provider 全量部署完成，再升级 customer。
发布顺序 先升级 provider：此时 provider 新旧接口同时在线，无论 customer 处于新版本还是旧版本，调用都能成功。 先升级 customer：滚动发布过程中会出现"新版本 customer + 旧版本 provider"共存的情况，新 customer 调用新接口，但旧 provider 并不支持，从而返回 400。最后旧接口可以在 customer 全部升级完成、确认无流量调用后再下线。一般可以在下一个版本就删掉旧版本接口。
Bayer PRINCE 生产就绪代理式 AI 系统案例研究的英文原文与中文对照版本。
从光亚展现场看智能化行业：大多数创新仍在硬件与固件，软件投入有限，制造业生态下的低成本创新与市场现实。
目标很直接：Clash 负责代理，Tailscale 负责组网，两边同时稳定运行。
实际问题通常是这样：Clash 开启 TUN 后，tailnet 访问异常；Tailscale 接管 DNS 后，Clash 的 fake-ip 解析又不稳定。
可行做法是：
Clash 排除 Tailscale 网段和网卡，Tailscale 关闭 DNS 接管。
一、为什么会冲突 两边都会改路由和 DNS，冲突主要有 3 个：
路由冲突 Clash TUN 默认接管系统流量，可能把 Tailscale 的 100.64.0.0/10 也带进去。
DNS 冲突 Tailscale 默认启用 MagicDNS，会改系统 DNS；Clash fake-ip 也依赖 DNS 控制，两边会互相干扰。
防火墙拦截 就算前两步都配好了，tailscale0 没放行的话，入站流量还是会被系统挡掉。
二、实操步骤 1) 先改 Clash：排除 Tailscale 流量 编辑文件：
1 ~/clashctl/resources/mixin.yaml 关键配置如下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 tun: enable: true stack: system auto-route: true route-exclude-address: - 100.64.0.0/10 exclude-interface: - tailscale0 dns: enable: true enhanced-mode: fake-ip fake-ip-filter: - "+.tailscale.net" - "100.64.0.0/10" 改完重启 Clash：
...