微服务应默认部署在私网，仅api网关等必要入口暴露有限公网能力；服务间通信必须走内网直连，对外调用统一由网关承载并走私网，跨域本质是策略而非网络问题。
公网与私网规划直接影响微服务跨域调用的安全性、性能和可维护性。关键不在于“能不能通”，而在于“该不该通、怎么通得稳又可控”。真实生产环境中，多数核心服务应默认部署在私网，仅网关、认证中心等必要入口暴露有限公网能力。
私网优先：服务间通信走内网通道
微服务之间（如订单服务调用库存服务）必须避免经公网中转。这不仅是延迟问题，更涉及安全暴露和链路不可控。
- 使用容器网络（如 Docker Compose 自定义 bridge 网络或 Kubernetes CNI 插件）让服务在同一个 VPC 或子网内直连，通过服务名（如 inventory-service:8080）通信
- 禁止将内部服务的端口映射到宿主机或绑定公网 IP；K8s 中应使用 ClusterIP Service，而非 NodePort 或 LoadBalancer
- 若需跨可用区调用，优先使用云厂商提供的内网高速通道（如阿里云高速通道、AWS PrivateLink），而非公网 + 安全组白名单
公网收敛：统一入口由 API 网关承载
对外提供能力的微服务，不直接暴露地址，而是通过 API 网关做统一接入。网关本身可部署在公网，但只负责路由、鉴权、限流，不包含业务逻辑。
- 前端、第三方系统等外部调用方，只知网关地址（如 https://api.example.com/order），完全不知后端服务真实位置
- 网关与后端服务之间走私网（例如网关 Pod 与订单服务 Pod 在同一 VPC 内通信），避免公网跳转引入额外延迟和防火墙干扰
- 网关启用 HTTPS + JWT 验证，并配置跨域（CORS）规则——只允许指定域名（如 https://app.example.com）访问，禁用通配符 *（尤其当携带凭证时）
跨账号/跨VPC调用：用私有连接替代公网穿透
企业多环境（如开发/测试/生产分属不同账号）、多中心（如主备 VPC）场景下，严禁用公网 IP + 密钥方式互通。
- AWS 场景：用 Interface VPC Endpoint + RAM 共享私有 API，调用流量全程不出 AWS 骨干网
- 华为云场景：通过 ROMA Connect 的微服务类型负载通道，自动对接 Service Registry，配合 VPC 对等连接实现跨 VPC 服务发现
- 自建环境：用 WireGuard 或 Tailscale 建立加密 overlay 网络，为各集群分配固定内网段，服务注册到统一 Consul/Nacos，按 namespace 隔离调用权限
跨域不是网络问题，是策略问题
浏览器报 CORS 错误，本质是前端请求发到了一个“协议+域名+端口”不同的服务上，而该服务没声明允许——它和网络是否公网/私网无关，只取决于响应头是否合规。
- OSS、CDN 等静态资源需单独配置 CORS 规则，允许特定来源读取（如 https://admin.example.com 可 GET 图片）
- 后端接口若被前端直连（非经网关），必须在响应中返回 Access-Control-Allow-Origin、Access-Control-Allow-Credentials 等头部；Spring Boot 可用
@CrossOrigin注解，.NET Core 可在Startup.cs配置策略 - 真正规避 CORS 的办法是：前端所有请求都走同源网关代理（如 Nginx 将 /api/** 转发到网关），让浏览器认为仍是同源请求
