我用 .NET 8 和 uni-app 做了一个小程序,想先验证一件事

最近我做了一个儿童专注力训练小程序。

前端用的是 uni-app，后端用的是 .NET 8 WebAPI。

这篇我不打算一上来就讲具体代码，也不准备把它包装成一个“已经做得很完整”的项目复盘。更准确一点说，它现在还是一个正在持续验证的 MVP。我更想先聊聊，这个项目为什么会开始，我第一版想验证的到底是什么，以及为什么我最后会选 .NET 8 + uni-app 这套组合。

为什么会想做这个项目

很多项目其实不是从“我已经想清楚完整方案了”开始的，而是从一个很具体的判断开始的。

这个项目对我来说也是一样。

我最开始在想的是：如果把专注力训练做成轻量的小程序，并且把训练这件事拆成足够短、足够容易开始的小任务，用户会不会更愿意尝试？如果再加上成绩记录、成长报告和分享能力，它会不会比一个单独的小游戏更容易形成持续使用？

换句话说，我不是先想做一个多大的平台，而是想先验证一条链路能不能成立。

这个链路很简单：训练能不能开始，结果能不能被记录，反馈能不能被看见，用户有没有理由继续回来。

我后来越来越觉得，很多所谓的 MVP 之所以最后没有真正验证出什么，不是因为页面做得不够多，而是因为一开始没有想清楚，自己到底要验证哪一个核心问题。

所以这个项目从一开始就不是“先把功能铺满”，而是“先把一条最关键的路径跑通”。

我第一版想验证的，不是功能多不多

如果只是做一个小游戏，其实并不难。

难的是，用户玩完之后为什么还要继续回来。

所以我第一版更在意的，不是功能数量，而是最基本的闭环是不是能成立。

现在这个小程序里，已经有几类核心能力：

训练入口：舒尔特方格、记忆翻牌、数独、华容道
结果沉淀：本地成绩、云端成绩、历史记录
反馈展示：成长报告、周训练小结、年度打卡日历
扩散能力：排行榜、成绩分享页、成绩广场

如果只看单个页面，它们都不算特别复杂。

但把这些页面串起来之后，项目的性质就变了。它不再只是“做完一局就结束”的小工具，而是开始有一点产品原型的样子了。

我自己比较看重的是“结果沉淀”和“反馈展示”这两层。

因为训练本身只是动作，只有当结果被记录下来，并且被用户感知到，训练才会真正变成一种可持续的行为。无论是面对家长用户，还是从产品验证的角度看，这一步都比“多加一个玩法”更重要。

所以如果要用一句话来概括这个第一版，我会说：我不是在验证“小游戏能不能做出来”，而是在验证“训练 + 反馈 + 分享”这条最小闭环能不能跑通。

为什么后端我还是选了 .NET 8

这个项目的后端我没有尝试太花哨的路线，还是老老实实用 .NET 8 WebAPI。

原因并不复杂，就是它对我来说足够稳，也足够顺手。

像这类项目，刚开始看上去只是几个接口，但只要你真的往下做，很快就会碰到一系列很典型的后端问题：登录态怎么处理、成绩记录怎么组织、本地和云端数据怎么衔接、排行榜查询怎么抽象、广场帖子和互动接口怎么设计、后续还有没有自然的扩展空间。

在这些问题面前，.NET 8 给我的价值其实很直接：工程化能力稳定，接口开发节奏顺，后续扩展也比较自然。

特别是在做 MVP 的时候，我其实不希望把太多精力消耗在基础设施层面。我更希望后端能给我一个足够稳定的底座，让我把注意力更多放在业务本身，放在“这条链路值不值得继续做”上。

从这个角度看，.NET 8 对我来说不是“最炫”的选择，但它确实是一个很省心的选择。

为什么前端用的是 uni-app

前端这边我选 uni-app，本质上也是同一种思路：先落地，再谈别的。

如果目标是尽快做出一个能在微信里跑起来的版本，uni-app 这条路的性价比其实挺高的。页面组织、组件复用、状态管理、微信端适配路径，至少在 MVP 阶段都比较直接。

我在这个项目里并不追求“前端技术姿势一定要最漂亮”，而是更在意另外两件事：第一，能不能尽快把页面串起来。第二，能不能把后面的迭代成本控制在一个还算舒服的范围里。

就这两个目标来说，uni-app 是够用的。

当然，够用不代表没有代价。做小程序时，平台差异、条件编译、分享能力、真机和开发环境差异，这些问题该来还是会来。只是对于当前这个阶段来说，它能让我更快进入“验证业务”的状态，而不是一开始就陷在技术选择本身。

这个项目里，我刻意保留了一些“看起来不那么优雅”的设计

做第一版时，有一个点我后来反而越来越认同，就是不要过早追求形式上的完美。

比如这个项目里，我保留了开发环境模拟登录，也保留了“后端不可用时仍然可以本地训练和看历史记录”的能力。

如果只从“架构洁癖”的角度看，这些设计未必显得那么漂亮。

但如果从真实验证的角度看，它们反而非常重要。

因为只要你的项目依赖真实微信登录、依赖后端始终可用、依赖所有远程链路都一次成功，那开发过程和验证过程都会被严重拖慢。很多时候你以为自己在验证产品，实际上你只是在被环境卡住。

所以我现在会更愿意接受一种不那么理想化的做法：先保证关键链路能跑，先保证在非理想状态下项目也能继续工作，然后再慢慢把它往更完整的方向推进。至少对 MVP 来说，我觉得这是更现实的。

做完第一版之后，我更确定了一件事

以前我也会下意识地把“做项目”理解成“把功能做出来”。

但这次做完第一版之后，我更强烈地感觉到，真正值得花时间的部分，往往不是某一个页面有没有完成，而是你有没有通过这个版本回答一个明确的问题。

这个项目目前还远远谈不上完整，后面也还有很多可以继续做的地方。

比如更完整的用户体系、更多训练模式、更细的报告维度、更稳定的分享和广场机制，甚至包括上线后真正的数据反馈，这些都还在后面。

但至少到目前为止，它已经帮我回答了第一步的问题：用 .NET 8 + uni-app 做这样一个小程序 MVP，是完全可行的；而且只要你不是一开始就把目标设得太大，很多想法其实是可以先做出来、先跑起来、再慢慢验证的。

这也是我最近做这个项目时最有收获的一点。

很多时候，真正卡住我们的不是技术做不到，而是我们总想等到“完全想清楚了”再开始。

但项目这件事，往往是先动手，很多问题才会变得清楚。

最后

这篇先不展开讲太多实现细节。

后面如果继续写，我更想拆开聊三件事：

我是怎么理解这个项目的功能闭环的
为什么我会保留本地成绩、本地可玩和模拟登录这些设计
在微信小程序这种环境里，哪些边界状态比我一开始预想的更麻烦

如果你也在做类似的“小程序前端 + WebAPI 后端”项目，或者你也在做某种需要先验证而不是先做大的 MVP，欢迎交流你通常会先验证什么。

对我来说，这类项目最有意思的地方，从来不只是技术选型本身，而是你怎么一步一步判断：这件事值不值得继续做下去。