99% 的人选服务器时，只盯着带宽和内存，却没问过自己一句：我的应用到底需不需要一直醒着？如果这个问题答错了，要么白白多花钱，要么在关键时刻掉线。Hosting 模式就是为了解决这个「选错模式」的隐形坑，让你的项目和服务器真正对上号。
有的站点像烟花，发布那一刻流量冲上去，过一会儿就归零；有的应用却像心电监护，哪怕一秒断线都不行。以前从「按需弹性」迁到「长期在线」模式，意味着一堆云配置、脚本、流水线要重来一遍，很多独立开发者和小团队被劝退。现在在 Manus Website Builder 里，只要点一下 Hosting 模式，就能在灵活省钱和持久在线之间切换。
据 Manus 内部数据反馈，很多用户一开始只用默认的弹性模式，直到做了第一个实时看板或机器人，才发现原来自己早就需要一台「不睡觉」的服务器。这篇就带你搞清楚：什么时候该用 Autoscale，什么时候必须上 Reserved。
掌控你的应用运行方式
让服务器行为跟着业务走
你是不是也遇到过：页面访问量不高，账单却一直不低；或者明明是实时应用，用户却总抱怨「刚打开就卡半天」？问题往往不在代码，而在运行模式。Hosting 模式的核心，就是让你自己决定应用在后台到底怎么跑，而不是被默认配置牵着走。
有的项目适合「有人来就开灯，没人来就关灯」，比如活动页、报名表、简单 API；有的项目则必须「灯一直亮着」，比如直播数据、监控、机器人。通过 Hosting 模式，你可以明确告诉系统：我要的是哪一种生活方式。说白了，就是把「省钱」和「稳定」这两个拉扯的目标，变成你可以随时调整的滑杆。
有用户反馈：在切换到合适的 Hosting 模式后，同一个项目的月成本下降了约 40%，而实时功能的稳定性反而更高了。
从开发体验上看，你不需要改一行代码，也不用重配 CI/CD，只是换了一个「引擎」。这点对个人开发者和小团队特别友好，精力可以继续放在产品本身，而不是云厂商的配置面板。
两种 Hosting 引擎的核心差异
Autoscale 和 Reserved 听起来像是云计算术语，其实可以简单理解成两种生活节奏：一位是「按需上班的自由职业者」，另一位是「24 小时值班的守夜人」。
- Autoscale（智能默认）：实例数量会在 0 到 5 之间自动伸缩，完全根据实时流量决定。
- 计费方式：只按「请求实际执行时间」收费，空闲时直接归零，站点闲着就是 $0。
- 适用场景：访问有波峰波谷、允许短暂冷启动的普通网站和工具。
- Reserved（常驻引擎）：固定一台长期在线的实例，不会被自动关机。
- 体验特点：没有冷启动、没有请求超时，连接可以一直保持。
- 适用场景：任何不能睡觉的应用，比如实时推送、长连接、后台任务。
有一位做数据看板的开发者，起初用 Autoscale，用户每次打开页面都要等几秒「热身」，后来切到 Reserved 后，页面几乎秒开，但成本也更可预期——这就是模式匹配带来的差异。
两种引擎，适配不同工作负载
Autoscale：按需唤醒的「聪明默认」
Autoscale 模式适合大多数「点一下、算一下」的应用。它的逻辑很简单：有人访问就拉起实例处理请求，没人访问就自动缩回去，避免服务器空转烧钱。对很多只在发布、活动、推广期有流量的项目来说，这种模式几乎是理想选择。
可以优先考虑 Autoscale 的典型场景包括：
- 产品落地页、个人作品集：发布当天流量冲高，夜里几乎没人访问，闲时成本为 $0。
- 内部报表或管理后台：只有有人打开时才需要计算和渲染数据。
- 表单类应用或轻量 API：每次只是按请求返回结果，不需要长时间保持连接。
数据显示，一些只在工作日白天有访问的企业内部工具，切到 Autoscale 后，月度云成本能直接砍掉一半以上。缺点也很现实：冷启动不可避免，偶尔会有一两秒的「刚醒」延迟，如果你的用户对秒级响应极度敏感，就要谨慎评估。
Reserved：为 24/7 场景准备的「常驻引擎」
Reserved 模式更像是给你的应用配了一台「专职值班服务器」。实例不会因为空闲就被关掉，连接可以长期保持，后台任务可以持续运行，这对实时和长连接场景非常关键。说实话，一旦你做过一次真正的实时系统，就会明白「永远在线」不是奢侈，而是刚需。
适合切换到 Reserved 的典型项目：
- 实时直播数据面板：持续推送比分、价格、传感器数据等实时信息。
- 实时摄像头查看：保持视频流不断开，避免频繁重连和画面中断。
- 聊天机器人或后台 worker：例如 Discord 机器人、消息队列消费者，需要 24/7 监听和处理事件。
有开发者分享，他的 Discord 机器人一开始跑在 Autoscale 上，结果每次实例被回收后，机器人就「装死」，直到下一次请求才重新连上。迁到 Reserved 后，掉线问题基本消失，但他也提到：如果只是偶尔跑个脚本，这种模式就有点浪费。这种取舍，我也不太确定每个人的感受是否一样，但大方向是清晰的。
为你的项目选对 Hosting 模式
一个简单的「三问判断法」
很多人纠结模式选择，是因为缺少一个直观的判断标准。可以试着用这三个问题给自己的项目做个小体检：
- 问题 1：应用是否需要保持长连接？
- 如果你在用 WebSocket、SSE、长轮询等实时技术，优先考虑 Reserved。
- 问题 2：用户是否能接受 1–3 秒的首次打开延迟？
- 能接受：Autoscale 更省钱；不能接受：Reserved 更稳。
- 问题 3：应用是否在后台持续处理任务？
- 有定时任务、消息消费、持续计算：更适合 Reserved。
一个经验法则：只要你的应用「哪怕没人盯着也在干活」，就把它当成 Reserved 候选；反之，更多是「有人点我才动」，Autoscale 往往就够用。
据一些云厂商公开数据，超过 70% 的小型项目其实并不需要 24/7 在线，却一直跑在常驻服务器上，白白浪费了预算。Hosting 模式的价值，就在于把这种浪费变成一个可以随时修正的选项，而不是一开始就写死的架构决定。
图示对比：Autoscale vs Reserved
从图上可以直观看到，两种模式在实例数量、计费方式、冷启动和连接保持上的差异。你可以把这张图当成团队讨论时的「对照表」，快速对齐预期。现实中最常见的错误，是所有项目一股脑丢进 Autoscale，结果实时功能各种掉线；或者反过来，全部上 Reserved，账单高得离谱。
一键切换 Hosting 模式
操作步骤：不用改代码的架构升级
切换 Hosting 模式的过程，被刻意设计得非常「不工程师」。你不需要打开终端，也不用写 Terraform 或 YAML，只要在 Manus Website Builder 的界面里点几下就行。对很多前端为主的团队来说，这种体验会轻松很多。
大致步骤如下：
- 打开已发布项目的设置页面，找到 Hosting mode 相关入口。
- 在弹出的对话框中，对比两张卡片：Autoscale 适合日常网站和通用负载，Reserved 适合后台任务、长时间运行和持久连接。
- 选中你想要的模式，点击 Save 保存配置。
- 如果想看更细的资源规格和计费说明，可以在对话框里点 View full specs in documentation。
切换过程由 Manus 在后台平滑处理，应用会保持可访问状态，不需要你额外做流量切换或灰度发布。
有团队在业务高峰前一周，把关键服务从 Autoscale 切到 Reserved，活动结束后再切回去，用这种「临时加班」的方式，既保证了稳定，又控制了成本。这种按阶段调整模式的玩法，其实很适合电商大促、直播带货等场景。
可用性与费用边界
目前 Hosting 模式已经对所有 Manus 用户开放，无需额外开通。每个账号每月会附带一笔 $10 的云资源额度，可在 Hosting 和数据库使用之间共享，这相当于给你一块「试错预算」，可以放心多试几种组合。
Reserved 模式的计费基于实际 CPU 和内存占用，在满负载情况下，大约为 $36/月 的上限。Autoscale 则完全按请求执行时间计费，空闲时不产生费用。风险点也很明确：如果你在 Reserved 上跑了一个资源吃紧的服务，又长期满负载不做优化，账单会非常接近上限，这一点需要在监控和预警上多下点功夫。
超越「普通网站」的构建空间
从静态页面到实时系统的跃迁
Hosting 模式看起来只是一个技术开关，背后却是你能做的产品形态的扩展。过去很多人用网站搭建工具，只敢做落地页、博客、简单后台，因为一旦牵扯到实时、长连接、机器人，就觉得必须上「重型云架构」。现在有了 Reserved 这种常驻引擎，这道心理门槛被大幅降低。
你可以更大胆地去尝试：
- 做一个实时比分或币价看板，给用户真正的「秒级更新」。
- 搭一个 24/7 在线的客服机器人或社区机器人，持续响应消息。
- 构建一个持续监听队列、定时任务的后台 worker，让业务逻辑真正自动化。
有用户在 Manus 上搭了一个实时交易监控面板，起初只是内部用的小工具，后来因为稳定性不错，干脆开放给客户使用，直接变成了一个收费产品。这类从「工具」到「产品」的跃迁，很大程度上依赖于底层 Hosting 能不能扛得住。
让选择变成优势，而不是负担
说到底，Hosting 模式的意义不在于多了两个名词，而在于把「怎么跑」这个原本复杂的架构决策，变成了一个可以随时调整的产品选项。你可以先用 Autoscale 快速验证想法，等项目跑通、有了实时需求，再一键切到 Reserved；也可以在业务淡季切回 Autoscale，减少固定支出。
这个判断方法在不少团队里已经被反复验证有效，不妨先收藏下来，等你下次要做实时功能或机器人时，再拿出来对照一遍。
如果你正站在「要不要做实时」「要不要做机器人」这种选择路口，这套 Hosting 模式的组合，往往比问十个朋友「你们服务器怎么配的」更有参考价值。每个项目都值得一个匹配它节奏的引擎，而不是被迫挤进同一种模板。
常见问题
Q：切换 Hosting 模式时，我的网站会短暂下线吗？
A：不会，切换过程中网站会保持在线。Manus 在后台平滑完成从一种模式到另一种模式的迁移，期间会并行管理旧实例和新实例，确保请求能够正常被处理。你不需要做额外的流量切换或灰度发布操作，只要在控制台里完成模式选择并保存即可。建议在非业务高峰时段进行切换，并在切换后简单自测关键功能是否正常，以增加安心感。
Q：Reserved 模式具体要花多少钱，怎么控制成本？
A：Reserved 模式按实际 CPU 和内存使用计费，在满负载情况下，大约上限为 $36/月。每个账号自带的 $10 月度额度会优先抵扣这部分费用，相当于帮你覆盖了一部分基础开销。成本的关键在于两点：一是是否真的需要 24/7 常驻，如果只是偶尔跑任务，可以考虑 Autoscale；二是要关注服务是否长期满负载运行，如果监控里 CPU 和内存经常打满，就需要优化代码或拆分服务，避免把 Reserved 当成「无限资源」来用。
Q：Autoscale 模式下还能用 WebSocket 吗？
A：技术上可以，但并不推荐这么做。Autoscale 的实例在空闲时会自动缩回到 0，这意味着长时间没有请求时，现有的 WebSocket 连接可能被中断，用户会感受到掉线和重连。对于依赖实时推送、在线状态敏感的应用，这种体验会非常糟糕。更稳妥的做法，是把 WebSocket、SSE 等长连接相关的服务放在 Reserved 模式下运行，而把普通页面、表单等短请求留在 Autoscale，以此兼顾体验和成本。
Q：怎么判断一个项目是否「必须」用 Reserved？
A：可以从三个角度来判断：是否有长连接（WebSocket、SSE）、是否有持续后台任务（定时任务、队列消费）、以及用户是否对首次打开速度极度敏感。如果这三项里有两项以上是「是」，就非常适合用 Reserved。原因在于，这类项目对「持续在线」和「稳定响应」的要求远高于一般网站，Autoscale 的冷启动和实例回收机制会带来明显副作用。实在拿不准时，可以先用 Autoscale 做原型，等实时和后台需求稳定后，再迁到 Reserved。
Q：切换模式会影响现有的部署流程或代码吗？
A：不会，Hosting 模式的切换对代码和部署流水线是透明的。你的项目依然通过原有方式构建和发布，只是在运行阶段由不同的引擎托管。Manus 在底层负责资源调度和实例管理，你不需要修改 CI/CD 配置，也不用引入额外的环境变量。唯一需要注意的是，如果你在代码里做了与实例生命周期强绑定的逻辑（比如假设进程永远不重启），就要重新审视一下，让应用在两种模式下都能健康运行，这样未来切换才更自由。
