去年冬天，云计我在一台跑着 Nginx 的云计旧笔记本上，把公司官网的云计静态页面全部迁到了对象存储加 CDN。整个过程没碰过服务器，云计连 SSH 都没登。云计改完 DNS 解析，云计泡了杯茶，云计刷新页面——加载时间从 2.3 秒掉到 400 毫秒。云计那一刻我意识到，云计云计算的云计 Web 早就不是「把网站放到别人的机器上」这么简单了。

很多人第一次接触「云 Web」，云计是云计从虚拟主机开始的。FTP 上传，云计MySQL 建库，云计控制面板点几下，云计网站就跑起来了。这套东西今天还在用，但它只是云 Web 的皮毛。真正的变化发生在架构层面。你打开一个现代 Web 应用，前端静态资源大概率躺在对象存储里，图片走 CDN 边缘节点，API 请求打到容器集群，数据库可能是托管服务，日志流进消息队列，定时任务由函数计算触发。这些东西彼此独立，按需伸缩，按秒计费。你不再维护一台「服务器」，而是在编排一组服务。

我见过一个典型的例子。某电商团队把促销页从单体应用拆出来，前端扔到 S3 加 CloudFront，后端订单接口用 Lambda 处理，数据库换成 DynamoDB 按请求付费。大促当天流量涨了四十倍，没人加班扩容，账单只多了几十美元。换成以前的 IDC 托管，光加机器就得提前一周申请。这种弹性不是魔法，是抽象层级的胜利。你写业务逻辑，云厂商负责物理机、网络、冷却、电力，还有那些你永远不想碰的 RAID 卡固件。

但云 Web 也有让人头疼的地方。冷启动。Lambda 闲置一段时间后第一次调用，延迟能飙到两三秒。用户点个按钮，转圈半天，体验直接崩。解法倒是有：预置并发、Provisioned Concurrency，或者干脆用 Fargate 跑常驻容器。可每加一层配置，复杂度就往上跳一截。我见过一个团队为了省几美元，把函数内存从 512MB 调到 128MB，结果 CPU 配额跟着缩水，执行时间翻倍，账单反而更贵。云服务的定价模型像迷宫，走错一步就多掏钱。

另一个坑是厂商锁定。你用了某家的 API 网关、IAM 策略、专有数据库，迁移成本高得吓人。我认识一个架构师，花了三个月把系统从一家云挪到另一家，光重写权限模型就耗掉一半时间。所以现在流行用 Terraform、Pulumi 这类工具做基础设施即代码，把云资源抽象成配置文件，换厂商时改几个参数就行。但说实话，真正迁起来，该疼的地方还是疼。

安全方面，云 Web 把边界搞模糊了。以前你守着防火墙，内网外网分得清清楚楚。现在 S3 存储桶配错权限，数据直接裸奔。Capital One 那起泄露事件，根因就是 WAF 配置失误加上 IAM 角色权限过大。云厂商提供了一堆安全工具，但默认配置往往不够安全，你得自己懂。责任共担模型不是口号，是实打实的操作要求。

成本控制也是门手艺。按需实例贵，预留实例便宜但绑一年，Spot 实例更便宜可随时被回收。你得根据负载曲线混着用。我习惯给每个项目打标签，月底拉账单，看哪块烧钱最多。有一次发现某个测试环境忘了关，跑了三个月，白交两千多块。云的好处是随时开，坏处也是随时开——没人提醒你关。

说到底，云计算 Web 的核心就一句话：把运维负担转移给平台，把架构决策留给自己。平台帮你扛硬件故障、网络抖动、机房断电，但你得想清楚怎么拆服务、怎么设缓存、怎么控权限、怎么省钱。这不是「上云就万事大吉」，而是换了一种方式干活。工具变了，问题没少，只是换了一批。

我现在写新项目，第一件事不是买服务器，是画架构图：哪些静态、哪些动态、哪些走边缘、哪些进队列。图画完，代码还没写，心里已经有底了。云 Web 教会我的，不是某个具体服务怎么用，而是先想清楚数据怎么流、请求怎么走、失败怎么兜。想明白了，再挑工具。反过来，先挑工具再想架构，多半要返工。