营销官网、Web 应用还是 PWA？

先问错了问题

几乎每一次首次沟通，我们都会听到这个问题：“我们应该做一个网站，还是做一个应用？”这是个错误的问题。它跳过了关键的一步。

正确的问题应该是：这个产品需要做什么，又是为谁而做？营销官网、定制 Web 应用和渐进式 Web 应用（PWA）解决的是不同的问题。选错形态不仅会浪费预算——还会把你锁定在一套难以推倒重来的架构里，而且往往要到六个月后、你收到第一轮真实用户反馈时，代价才会显现。

下面是我们在写下第一行代码之前，与客户一起使用的判断框架，以及 2026 年这几种方案各自的真实成本区间和周期。

三种不同的任务，而非同一任务的三个层级

很多团队把这三者看作一个阶梯——官网在底层，应用在中间，PWA 在顶层。这种理解并不准确。它们并非彼此更复杂或更简单的版本，而是在回答不同的问题。

营销官网。 任务：把访客转化为线索或订单。以内容为核心，大部分内容公开，没有用户账户体系（或者只为内容付费墙加了一层很薄的账户功能）。成功与否看转化率、加载速度和搜索排名。通常基于 CMS 或静态站点框架搭建，除了表单和数据分析之外很少需要自定义后端逻辑。

定制 Web 应用。 任务：让经过身份验证的用户完成真正的工作——管理库存、审核理赔、预约、生成报表。业务逻辑都在这里：权限、工作流、数据校验，以及与 CRM 或 ERP 的集成。衡量成功的标准是任务完成时间和错误率，而不是页面浏览量。

PWA。 任务：让 Web 应用拥有原生应用的体验——可安装的图标、关键页面的离线访问、推送通知——同时省去 App Store 的审核流程和两套独立代码库。与其说它是第四种类别，不如说它是叠加在 Web 应用之上的一种交付方式。你不是“做一个 PWA”来代替 Web 应用，而是先做好 Web 应用，再决定要为它叠加多少 PWA 层(Service Worker、离线缓存、安装提示)才值得。

到底该怎么选

按顺序问自己以下四个问题：

1. 用户是登录后反复完成某项工作，还是访客看完就走？ 反复性工作 → Web 应用。看完就走 → 营销官网。
2. 产品是否需要在网络不稳定、用手机、远离办公桌的场景下也能用？ 外勤技术人员、仓库员工、配送司机——需要。网络稳定的办公室知识工作者——通常不需要，这时 PWA 层只是你暂时用不上的额外开销。
3. 搜索可见性是不是用户找到你的方式之一？ 如果是，这些内容就需要放在一个加载快、可被抓取的营销官网上——而不是藏在应用的登录墙后面，并且需要从第一次提交代码起就内置技术基础（SEO 的基本功：服务端渲染的内容、干净的 URL、可用的结构化数据），而不是上线之后再补。
4. 你是不是两者都需要？ 大多数 B2B 公司都是这样：用官网获取线索，用登录后的 Web 应用承载真正的付费客户。这是两个项目，不是一个——把它们当成一个项目来做，正是 Web 项目预算超支的常见原因之一。

如果你要做的是第二种——客户真正会使用的那个应用——这正是我们的Web 开发团队投入大部分精力的地方，因为成本和风险都集中在这里。

真正决定成本的因素

成本主要不取决于页面数量或“功能多少”，而是取决于以下四件事：

数据模型复杂度。 一个只有少量简单实体类型的 CRUD 应用，和一个跨多种实体类型、带角色权限和审计日志的应用，完全是两种不同规模的项目。每新增一层关系，增加的不只是数据表结构，测试面也会成倍扩大。

集成。 你接入的每一个第三方系统——Stripe、Salesforce、物流承运商的 API、内部的老旧数据库——都会实实在在地增加工期，具体多少取决于该系统 API 的文档完善程度和稳定性。没有文档的内部系统，是我们见过项目延期最常见的原因之一，因为很多边界情况只有在真正开始对接之后才会暴露出来。

实时与离线需求。 一个刷新页面才更新数据的仪表盘成本很低。而一个通过 WebSocket 实时更新的仪表盘，或者一个需要在无网络状态下工作、之后再同步数据的移动端页面，会在受影响页面的基础开发工作量之上，再增加实实在在的工程时间。

设计成熟度。 如果你手上已经有一份 Figma 文件，把每种状态（空状态、加载中、报错、边界情况）都设计好了，开发就能推进得很快。如果设计和开发是并行进行的，就要预留返工的时间——因为页面是按照一份还在变动的设计稿开发出来的。

团队的资深程度和所在地区会影响时薪，但很少是项目总成本大幅波动的真正原因。真正的原因是上面这四个因素。

2026 年的现实周期

以下是基于我们近期评估的项目给出的大致区间，适用于单个范围明确的项目——而不是大型企业可能需要的全部项目组合：

• 营销官网（几个页面，基于 CMS，无需自定义后端）：几周时间。
• 定制 Web 应用，标准复杂度（身份验证、几种核心实体类型、一到两个集成）：大约一个季度。
• 定制 Web 应用，高复杂度（多角色权限、多个集成、实时功能）：两个季度或更长。
• 为现有 Web 应用叠加 PWA 层（关键页面离线缓存、安装提示、推送通知）：几周时间，具体取决于应用中有多少部分需要真正离线可用，而不只是可安装。

任何没有问过你的数据模型、集成情况和设计进度就给出固定报价的人，都是在猜。

我们见过最多的模式

最常见的错误不是选错了形态，而是选定一种形态之后，却指望它同时完成两项任务。一家公司先做了一个漂亮的营销官网，然后因为“反正代码都已经写好了”，就想在同一个代码库上硬塞进一个客户仪表盘。几个月后，仪表盘开始和 CMS 争夺路由控制权，每一次内容更新都可能弄坏某个登录后的功能。

解决办法几乎总是一开始就把两者拆开：一个为速度和搜索优化的轻量营销官网，和一个为登录体验优化的独立 Web 应用，两者共享设计系统，但不共享代码库。前期投入会略高一些，但能省下后面的一次重建。

结论

不要从“做官网还是做应用”开始。先看用户到底在做什么，其中有多少必须在糟糕的网络环境下也能用。把营销官网和登录后的产品当作两个独立的决策来评估，即使最终是同一个团队来做。在给定制项目估价时，先问数据模型和集成情况，再问页面数量——真正的报价是从前者算出来的。

如果你正准备启动其中一类项目，想为自己的具体情况得到一个关于成本和周期的直接答案，在写 RFP 之前先来和我们聊聊。