出海产品死法很多，最常见的一种是：国内跑得好好的，搬出去突然全崩了——不是代码问题，是架构里根本没考虑过「地球是圆的」。
这篇是我把出海产品从 0 搭到全球可用的清单式复盘，按踩坑顺序写：网络层、数据层、合规层、商业层。都是架构决策，不是运维细节。
第一层：网络——先回答「用户在哪个机房附近」
- 就近接入：第一版不用「全球多机房」，用 CDN + 边缘函数解决静态与轻计算；动态接口先在 AWS/Cloudflare 覆盖好的区域放 1–2 个入口节点。
- 延迟预算：把 P99 目标拆到每跳（用户→CDN→入口→业务→DB）。跨洋链路是物理现实，别指望优化代码绕过 200ms 的底线。
- 全球可观测性：入口层的探测（synthetic probes）必须覆盖目标市场本地——上海机房看洛杉矶的用户延迟，永远是「看起来很快」。
踩坑记录：第一版只在美东一个区，东南亚用户 P99 2.8s，上线一周流失率离谱。后来在东京加了接入点，东南亚 P99 掉到 600ms 以内。先解决「近」，再优化「快」。
第二层：数据——数据主权是硬约束，不是偏好
- 启动前先画一张「数据地图」：哪些数据在哪个区、能不能出境。这张图决定你后面所有的架构选择。
- 合规要求因市场而异（欧盟 GDPR、各国的数据本地化、未成年人保护），以目标市场律师的书面意见为准，不要照抄国内经验，也别信网上的二手总结。
- 数据库默认按区域隔离起步：跨区复制是「需求明确后」再加的能力，不要一开始就全局多主。
第三层：合规——三件容易被忽略的事
- 未成年人保护：做陪伴/社交/AI 对话类产品，目标市场对未成年人有严格规定，身份校验不能只靠「点一下我成年了」。
- 内容与生成物：AI 生成内容要能下架、要留审计日志——「生成什么我不管」在出海市场行不通。
- 隐私文档不是翻译：隐私政策、用户协议要按目标市场法律重写，不是把中文版机翻成英文。
第四层：商业——支付与风控决定能不能收到钱
- 支付优先用托管收单（Stripe / Paddle / Lemon Squeezy），把税务、发票、订阅管理的合规成本外包出去——独立开发者尤其别自建支付（工具行里我写过）。
- 风控别照搬国内：海外卡拒付、争议处理、地址验证的逻辑和国内支付完全不同。
- 订阅产品把「退款/取消政策」写清楚，否则争议仲裁会吃掉利润。
一套能直接用的检查单
- 数据地图画完，标出每个数据的存储区与出境路径
- 接入 CDN + 至少 2 个区域入口，P99 目标拆到每跳
- 目标市场合规意见（律师）已拿到并归档
- 未成年人、内容下架、审计日志三条已落地
- 支付走托管收单，税务/发票合规外包
- 全球合成探测已上线，本地市场能看到真实延迟
出海的每一步其实都在回答同一句话：用户在世界的另一边，你的架构要当它不存在这条线。 支付与增长的成本账，我在独立开发者出海那篇里继续写。