1.1 传统服务器 vs 托管平台：运维减法

这本书的项目主角是一个前端开发者，技术栈是 Node（TypeScript），写的是一个 Vue 静态创业页。在决定用托管平台之前，我在一台 2 核 4G 的云服务器上跑了八个月同一个站。这八个月我没写一行业务代码，全在修服务器。本节就是这份“运维账单”的复盘：托管平台到底帮你减掉了哪些活，哪些活它减不掉、你必须自己兜。如果你正犹豫要不要把静态站迁到 网站托管 CloudPages 这类平台，这篇复盘应该比任何宣传页有参考价值——它完整记录了我把时间花在了哪些根本不需要花的地方。

先说清楚一个前提：静态站没有服务端进程。它说到底就是一堆 html、js、css、图片文件，需要的是一块“能被公网访问的存档空间”加一条 HTTPS 入口。传统服务器为了提供这个能力，附赠了整台操作系统的运维；托管平台则只收文件、只返回文件。这个差异决定了后面所有的对比。理解这个前提之后，1.2 节的选型对比表看起来就不是两个“等价方案”的竞争，而是两个不同抽象层的选择。

1.1.1 场景：一台服务器能占掉多少时间

八个月里我处理过的真实事件，按时间排：

要注意上表里“耗时”一栏的真实含义：我不只是花了这些时间，而是这些时间全部被打散在工作日的高峰期。扫描器凌晨三点来，我就得凌晨三点起来看；证书续期失败记得是周末发现站打不开的。服务器出问题不挑时间，而静态站的流量低谷恰恰是凌晨——故障伤害度被放大了一倍。

最讽刺的是：站本身从没出过 bug。页面好好的，坏的都是承载它的那台机器。我老婆问我最近在忙什么，我说在给服务器打补丁，她说“你的网站不是只有一页吗”。

这句话把我问醒了。一个访问量并不大的静态页面，凭什么需要一个会呼吸、会生病、需要人定期照看的操作系统？我算了一笔时间账：八个月里真正用于“让网站变得更好”的时间不到总投入的三成，其余全花在维护载体上。对一个两人小团队，这个比例是致命的——我们的核心资产应该是页面内容和产品迭代，而不是对一台机器的熟稳度。

1.1.2 运维减法清单：这些活平台替你做了

托管平台（比如腾讯云网站托管 CloudPages）的本质是把这些“机器层面的琐事”打包成平台能力。逐项对照：

这张表里最值钱的是“证书续期”和“防攻击”两项。前者听起来日常，但证书过期导致的站打不开是低级却高频的故障；后者对小团队是无底洞，攻击流量来一次，自己扛基本等于停服。

1.1.3 减不掉的活：别误以为托管等于甩手

广告不会告诉你的是，托管平台减掉的是“机器运维”，而不是“内容运维”。这些活仍然在你手上，平台一句疑问都不会帮你解决。托管不是免责声明，而是责任转移：把机器的责任转移给平台，换来的是你必须对内容、缓存、发布流程负责到底。

构建与发布流程。 文件传上去之前总要有构建过程。vue-router 的 base 路径配错、构建产物里残留绝对路径、图片没压缩传上去流量费翻倍——这些都是我在这本书后面章节反复要讲的。平台不帮你 build。

缓存与刷新。 CDN 缓存是你的站变快的核心，但缓存一旦忘记刷新，用户看到旧版页面骂的还是你。第五篇会专门讲刷新策略。我们最尴尬的一次是改了价格表忘了刷新，销售在外面跟客户说新价格，客户打开手机一看旧价格，当场信任崩塌。从那以后刷新动作被写进了部署脚本，成为发布流程不可省略的一步。

域名与 DNS。 平台给你的是默认域名，自定义域名要自己解析、自己验证所有权。域名有效期、解析记录、备案，一样都不能少。

成本预算。 托管平台按量计费对小流量友好，但如果哪天被刷流量，账单也可能失控。这事的应对方案放 1.3 费用与免费额度。

1.1.4 托管平台的运行机制：三件事必须先知道

迁到平台之前，有三条机制先弄清楚，否则后面处处是玄学：

文件不在“服务器”上，而在对象存储里。 你传上去的 dist 会被放进类似 COS 的存储桶，平台在前面挂一层 CDN。用户请求时先打最近的 CDN 节点，没有才回源到存储。所以“部署成功”其实是“文件进了存储桶并且缓存刷新生效”。

默认域名是平台借你的，不属于你。 形如 xxx.tcloudbaseapp.com 的域名随时可能因平台规则调整而变化，正式项目必须绑自己的域名。域名相关的完整流程在 3.2 域名与解析，这里只强调一条：别把默认域名印到名片和宣传材料上。

环境是隔离单位。 一个账号下可以开多个环境，测试环境和生产环境分开是最基本的纪律。我们团队的做法是任何改动先上 test 环境验证，再合并到 main 触发生产部署，这套流程在 5.1 CI/CD 里完整展开。

1.1.5 一次对照实验：同一个站两套部署

我做过的最直观的验证：同一个静态创业页，两条线并行跑一周。

传统服务器这条线，发布一次的完整命令是：

# 本地构建
npm run build

# 上传（还得先确认 rsync 在服务器上可用）
rsync -avz --delete dist/ user@server:/var/www/site/

# 远程检查 nginx 配置没被改坏
ssh user@server "nginx -t"

# 重载并验证
ssh user@server "systemctl reload nginx"
curl -I https://example.com

托管平台这条线：

npm run build
# 平台 CLI 或 git push 触发，平台自动接管分发与 HTTPS
npx tcb deploy --path dist

前者五条命令、两台机器、四种失败可能（网络、权限、配置、缓存）；后者一条命令，失败原因只有明确的几种。从“一个人维护全链路”变成“一个人写好构建脚本，剩下交给平台”，这就是运维减法的体感。

1.1.6 我的两个反面教训

教训一：把托管平台当服务器用。刚迁移那阵，我习惯性地问“能不能 ssh 进去看看”，还想找 nginx.conf 改个 header。平台没有这些入口，方向就错了。正确问法是“平台提供什么配置项”，活在自己的 abstraction 里，比自己造轮子省心。

教训二：迁了平台就不学基础。托管不等于你可以不懂 HTTPS、不懂缓存。出问题时平台只给现象，诊断还是要靠基础知识，所以 1.2 节我会专门留一节讲“即使选了托管也要懂的东西”，第五篇再补上监控告警。另外还有一个小教训值得记：迁移别在业务高峰做，我们选在了周日上午，理由是当天即使出问题也有完整时间修，而不是周五晚上留下烂摊子。

小结

对静态创业页这种场景，托管平台把运维从“管机器”变成“管发布”。你放弃的是对底层的控制权，换来的是证书、防护、备份、扩容四件大事全部脱手——这几件事恰好是小团队最容易出血故障的地方。代价是你要接受平台的规则：构建自己搞定、缓存策略自己设计、费用自己盯住。下一节 1.2 选型对比：自建 Nginx vs 网站托管 把两条路线的正反两面摆全。

延伸阅读

• 1.2 选型对比：自建 Nginx vs 网站托管：本篇下一节，逐项打分两条路线。
• 轻量应用服务器建站实战：如果你确实需要一台服务器（比如有动态接口），先看这本。