不用写代码，把网站转成 App 的三条路

把已有网站变成用户能装到手机上的东西，过去意味着请开发、再多养两套代码。现在不必了。对内容站、电商站和服务类站点来说，不用写代码把网站转成 App 是可行的——但这句话能兑现到什么程度，完全取决于你走哪一条路。

这篇讲清楚三条路各自产出什么、后续维护要付什么代价、以及怎么判断自己的站适合哪条。

先分清「App」指的是哪一个

在比较工具之前，先把两件被统称为 App 的事分开：

• 一个能装的图标 + 独立窗口：从桌面启动，没有浏览器地址栏，能发通知，断网也能打开一部分。
• 一个应用商店里的条目：通过 Google Play 或 App Store 分发，能被商店搜索到，要过商店审核。

第一件事，不写代码就能做到。第二件事，不写代码也能做到，但它多出一道审核——这道审核跟你的技术水平无关，只跟你的类目和内容有关。很多人觉得「无代码做 App」名不副实，正是因为把这两件事混为一谈：他们拿到了图标，期待的却是商店条目。

路线一：渐进式网页应用（不打包、不进商店）

渐进式网页应用（PWA）把你现在跑的这个站直接变成可安装的。你只需要往站点里加两样东西：一个 web app manifest（一个小 JSON 文件，写明名称、图标、启动地址和显示模式），和一个 service worker（一段脚本，把资源缓存下来，让应用不用等网络就能打开）。

两样都不需要你去「做一个 App」。多数建站平台在设置面板里就能生成，自建站则是上传一个文件的事。

你会得到：桌面图标、无地址栏的独立窗口、访问过的页面可离线打开、安卓上的网页推送。发布即更新，没有重新提审这回事。

你不会得到：应用商店里的位置；而且 iOS 上的能力明显比安卓窄。安卓和桌面 Chrome 会给出真正的安装提示，iOS 则要用户自己点「分享」再点「添加到主屏幕」——这是实打实的转化成本，应该在设计上正面处理，而不是假装它不存在。这个提示在各平台的真实行为、以及流失有多少是可以救回来的，值得先看明白：添加到主屏幕提示在各平台到底怎么触发。

适合谁：价值就在内容或交易本身的站点——媒体、商品目录、预订、数据看板、网店。如果你的站今天在手机浏览器里就好用，它做成 PWA 也会好用。

路线二：用原生壳把站点包起来

包壳工具接收你的网址，产出一个可安装的包：安卓是 APK，iOS 是 IPA。包体里是一个全屏 web view 在加载你的站点。好几家托管服务用一个表单就能做完——填网址、图标、名称，拿到构建产物。

你会得到：一个真实的安装包，可以自行分发、提交商店、或者直接发给用户。壳这一层还能补上开放网页在某些平台够不到的能力，最常见的是 iOS 推送和一部分设备接口。

代价是什么：包是构建产物，会过期。改站点内容是即时生效的，但只要动到壳本身——图标、权限、SDK 版本、最低系统版本——就得重新构建、重新分发。如果你上了商店，每一次重构建都是又一轮审核。

必须知道的翻车点：各大商店都明确写着，一个只是加载网页、除浏览器已有能力外别无功能的包，有被判「功能过于单薄」而驳回的风险。能过审的包壳产品，一般都补了网页做不到的东西：离线内容库、原生通知处理、硬件集成。光靠包壳不构成一个上架方案。

路线三：在无代码平台上重做一遍

第三条路其实不叫转换：你在无代码搭建平台里把体验重做一遍，通过 API、CMS 或表格接上原有数据。网站还在原地，App 变成同一批内容的第二个前端。

你会得到：真正的原生组件、正规的商店分发、完整的设备能力。

代价是什么：从此有两个产品。每一次内容模型调整、每一种新页面类型、每一次改价，都要落两遍。团队普遍低估这件事，因为搭建很快，而分叉是几个月后才出现的。

适合谁：App 需要做一些和网站结构上就不同的事——积分体系、离线优先的现场工具、带设备能力的会员区。如果 App 就是想等于网站，这条路的机械成本远超需要。

三条路怎么选

可以直接用的判断规则：如果「我们为什么需要 App」的答案是商店位置，那就得走路线二或三；如果答案是更快打开、更容易回来、更容易再触达，路线一用最小的新增面积就能做到。

大部分在问「不用写代码怎么把网站转成 App」的团队，描述的是后一个问题，伸手去拿的却是前一个方案。

一个务实的推进顺序

1. 先体检移动站本身。 建在又慢又难用的移动站之上的 App，会把两个问题一起继承下来，再用一个图标盖住。先修布局、速度和结算，再谈打包。
2. 加 manifest 和 service worker。 名称、各尺寸图标、display: standalone、启动地址、主题色。用浏览器的安装审计去验证，别靠肉眼看。
3. 决定缓存什么。 外壳和静态资源一律缓存，内容页按策略来。全缓存会出现陈旧页面，全不缓存则会出现断网即失败还没有任何提示的应用。
4. 认真设计安装那一刻。 别在首屏就弹提示。放在用户完成一个动作之后再触发，并且为 iOS 单独写一段说明，而不是假装两个平台行为一致。
5. 别弄坏可被收录的站点。 加一层可安装外壳，不应该改变爬虫看到的东西。客户端渲染的内容、被挡住的资源、重复的 URL，都是出问题的地方——类 App 站点常见的 SEO 坑在你加壳的那一刻就开始适用。
6. 最后才考虑打包。 如果可安装的站点上线之后，商店位置依然重要，那就去包壳——并且记住「功能过于单薄」这条红线。

第一步是最容易被跳过的，也是最终决定成败的那一步。

该看哪些数

没人安装的 App，只是一次多了几道工序的改版。盯四个数：

• 提示曝光 → 接受安装（漏斗最上层，也是提示设计能撬动的那个数）
• 安装 → 至少打开两次（这个图标到底有没有用）
• 已安装环境的会话 vs 浏览器会话（真实的行为差异，不是虚荣指标）
• 离线会话里完成了动作的比例（你的缓存策略对不对）

如果第二个数很差，问题出在「再次进来」这件事本身没价值，而不是打包方式。壳做得再精细也救不回来——这一点最好在你决定长期维护一条构建流水线之前就搞明白。其中落差最大的就是离线表现，service worker 到底能救回什么、救不回什么，建议在向用户作任何说明之前先读一遍。

常见问题

把网站转成 App 可以零成本吗？

PWA 这条路没有授权费用——manifest 和 service worker 是放在你自己站点上的文件，主流浏览器都支持安装，不设付费门槛。托管型包壳服务通常按构建次数或按月收费，商店分发还有开发者账号费用（Google Play 是一次性，Apple 是按年）。所以「零成本」对路线一是准确的，对另外两条是误导。

转出来的 App 在安卓和 iOS 上表现一样吗？

不一样，而且处理这个差距本身就是主要工作量。安卓支持真正的安装提示、网页推送和更完整的安装界面；iOS 只能通过分享菜单安装，存储回收更激进，网页推送的支持也一直落后。默认假设是：安卓走顺路，iOS 需要一段明确的图文说明。

转换后的网站能上 Google Play 吗？

可以，通过包壳或者 Trusted Web Activity（把 PWA 打包成安卓应用）。但过审不是自动的：商店会驳回那些除了浏览器体验之外没有任何增量的包。现实的要求是，这个包得做点书签做不到的事。

把站点做成 App 会影响 SEO 吗？

单纯做这件事不会——可安装的那一层是叠在同一批页面之上的。出问题的是转换过程中改变了内容的交付方式：内容要等 JavaScript 才渲染、service worker 给爬虫返回一个空壳、或者用一个 app 子域把主站内容复制了一遍。保持 URL 和服务端渲染的内容稳定，风险就很低。

现实中要花多久？

给一个健康的站点加上 manifest 和基础的 service worker，是一天的工作量。让安装率高到对得起这份投入，则要久得多，因为那取决于提示时机、用户感知到的价值，以及底下那个移动端体验本身。技术这一步不是慢的那一步。

不用写代码把网站转成 App 确实做得到，功夫在于让路线匹配你的动机。ROIBest 做的是这个决策里 PWA 的那一侧：可安装的交付、推送再触达，以及移动网页流量的投放度量。