来源：对 PR #111（多站点同步，commit 4a424ce）的代码 review，非用户上报。
现象 / 影响
多平台部署逐个平台复用同一个 output 目录（backend/internal/service/deploy_service.go 的 DeployToRemote 在循环里依次部署到每个已启用平台）。
backend/internal/deploy/git_deployer.go 的 GitProvider.Deploy 只在「当前平台配置了自定义域名」时写入 output/CNAME，从不删除上一个平台残留的 CNAME。
触发条件
同时启用「带自定义域名的 GitHub」+「不带域名的 Coding」（顺序任意）：
- 先部署的平台把自己的域名写进
output/CNAME；
- 轮到下一个 Git 平台时，该
CNAME 仍残留在 output/，被 AddWithOptions{All: true} 提交并 force push；
- → 下一个平台的仓库被带上了别人平台的域名。
说明（哪些是安全的）
remote 本身没问题：每轮 DeleteRemote("origin") + 重建，不会把内容推错仓库。问题仅在于 CNAME 这个文件在目录里残留、跨平台串了。
建议
每轮部署前按当前平台重写 CNAME：该平台有自定义域名则写、没有则删除残留的 output/CNAME。
现象 / 影响
多平台部署逐个平台复用同一个
output目录（backend/internal/service/deploy_service.go的DeployToRemote在循环里依次部署到每个已启用平台）。backend/internal/deploy/git_deployer.go的GitProvider.Deploy只在「当前平台配置了自定义域名」时写入output/CNAME，从不删除上一个平台残留的 CNAME。触发条件
同时启用「带自定义域名的 GitHub」+「不带域名的 Coding」（顺序任意）：
output/CNAME；CNAME仍残留在output/，被AddWithOptions{All: true}提交并 force push；说明（哪些是安全的）
remote 本身没问题：每轮
DeleteRemote("origin")+ 重建，不会把内容推错仓库。问题仅在于CNAME这个文件在目录里残留、跨平台串了。建议
每轮部署前按当前平台重写 CNAME：该平台有自定义域名则写、没有则删除残留的
output/CNAME。