技术路线与产品形态怎么选

选型不要从"哪个框架最流行"开始，要从第一版要验证什么开始。

同一个想法，做成网页、小程序还是 App，后面三个月的工作量能差三倍。这个决定做错，比用错一个框架贵得多。

先定形态，再定技术

前两行不需要账号系统，第三行不需要应用商店，第四第五行会把成本和周期整体抬高一档。

先确认第四第五行是不是真的必须。 "以后可能要用推送"不算必须。

形态决定了后面所有的连带成本

早期真正重要的只有五件事

• 用户能不能打开
• 核心流程能不能跑完
• 你能不能当天改完
• 数据和反馈能不能收回来
• 部署、域名、支付不要卡住主线

"能不能撑到一百万用户"不在这个列表里。没有用户的时候，扩展性不是问题。

三条路线的选择逻辑

不按产品名记，按能力要求记。

国内 C 端、用户在微信里

需要的是：小程序载体 + 一套自带数据库和函数的后端服务 + 平台内的支付和登录。

选这条路的前提是你的用户本来就在微信里完成这件事，而不是"微信用户多"。用户多不等于你的用户在这里。

配套费用见国内路径的成本，登录方案见微信登录。

国内 Web 应用或管理后台

需要的是：一台云服务器 + 一个能简化部署的工具 + 一个低运维数据库 + 一个已备案域名。

不需要小程序载体的产品别硬套小程序，网页改起来自由得多。

面向海外用户

需要的是：一个能一键部署的托管平台 + 平台自带的域名和 DNS + 边缘节点覆盖 + 一个国际收款通道。

这条路不需要备案，主体也可以晚一步再办。费用结构见海外路径的成本。

数据库先选低运维的

默认选内嵌式或平台托管的轻量数据库。满足下面任一条时，再换成更重的关系型数据库：

• 明确需要高写入并发
• 需要特定扩展能力或专属事务特性
• 已经依赖某个平台的权限规则和认证体系

判断句：我现在能说出「为什么必须用更重的数据库」吗？
说不出来 → 用轻量的

"以后可能要扩展"不是理由。 迁移数据库是一天的活，选错方向浪费的是三个月。

不要在这一层反复横跳

选型花三天，用三年。两个常见的时间黑洞：

• 反复比较两个功能等价的框架
• 在还没有用户时纠结数据访问层

什么时候才该重构

只在这四种情况下考虑：

1. 有付费用户了，方向被验证了
2. 改一个功能要花一周
3. 性能已经影响到用户
4. 有明确的安全风险

四条都不满足时，重构是一种精致的拖延。

常见错误

从框架开始选，而不是从形态开始。 形态错了，框架选得再好也白做。

为"以后可能要用"的能力提前选重形态。 推送、定位这类需求要确认是第一版必须。

默认认为国内用户就该做小程序。 要看你的用户是不是本来在微信里完成这件事。

在没有用户时纠结扩展性。 扩展性是有用户之后的问题。

选刚发布的新框架。 AI 写不好，你也查不到解法。

同时想要国内和海外两条路。 第一版只选一个主市场。

验收标准

• 能用一句话说出第一版的形态，理由和"要验证什么"直接相关
• 知道这个形态会带来哪些连带成本和审核周期
• 摄像头、定位、推送这类原生能力已确认是不是第一版必须
• 数据库选了低运维的，或者能说出为什么必须选更重的
• 技术栈是主流的、文档多的
• 只选了一个主市场
• 部署路径已经想清楚，不是留到最后再说

本章动作

写下这两句：

第一版形态：______，因为我要先验证______。
技术路线：______，我能在______天内部署上线一个空壳。

第二句里的天数如果超过一周，换一条更简单的路线。

下一步

1. 从模板起步——不从零写的选型标准
2. 不写代码也能做出第一版——先用现成工具验证
3. 一天做出可打开版本——路线定了就开工