这里是项目的 Github仓库 ,里面既有简单的完善代码质量任务，也有作者完全搞不定的各式难题，无论你是单纯想熟悉一下PR流程，还是愿意帮助作者完善项目，亦或是看完文章之后想了解一下实现方式，这里都欢迎你的到来！
你觉得，实现这么一个看起来只有两页的简单APP需要多久？
很多人的第一反应可能是：两天？
而我的答案是：整整18天 ，并且每天肝将近16个小时。
为什么？因为作为一名即将大二的野路子前端，这不仅是我第一次接触 Uniapp，更是第一次真正独立完成一个全栈项目 。它与我之前照着B站视频亦步亦趋做项目有着根本上的不同。
因此，我决定写下这篇文章，把我这18天里总结的所有经验教训分享出来。虽然项目基于Uniapp X，但我认为不管使用哪个技术栈进行开发，这篇文章都会对你有所启示。
事先声明
本人只是一名即将大二的前端初学者，文内总结的内容都只是我的个人经验和看法，是面向和我一样从未开发过全栈项目的前端小白所作。
如果你是经验丰富的前端大佬 ，欢迎你移步我的Github仓库，为这个小小项目提出一些宝贵的 Issue 或者 PR。你们的任何一句指点，对我来说都是巨大的帮助。
当然，你也可以继续看下去，如果有哪些地方我说得片面或者有误，也欢迎在评论区里指出或纠正。
选型：光环之下的 "隐形成本"
为什么选择 Uniapp X？
我的初衷非常简单。放眼国内市场，移动端（尤其是小程序和APP）的开发需求依旧旺盛。作为一名 Vue 技术栈的开发者，Uniapp 那句 "一端编译，多端运行" 的口号深深吸引了我。而 Uniapp X，作为其未来的迭代方向，主打能编译成原生应用，性能更强，这听起来简直是完美的解决方案。于是，我毫不犹豫地将它定为项目的主要技术框架。
然而，经过一番实践和复盘，我才意识到，对于许多开发者（尤其是新手）而言，技术的"新"和"强"，往往伴随着你必须仔细评估的隐性成本。
隐性成本一：功能覆盖 ------ 你需要的功能它支持吗？
选择一个框架，我们不能只看它"有什么"，更要看它 "没什么" 。
Uniapp X 为了实现代码到原生的编译，舍弃了大量在 Web 端常见但在原生端难以兼容的特性。比如 CSS 中的 3D 变换、径向渐变、伪元素、伪类选择器......这些在 Web 开发中信手拈来的工具，在 Hbuilder 编辑器里都变成了刺眼的黄色波浪："不支持"。许多酷炫的想法，在诞生的那一刻就因为框架的限制而被迫放弃。
你可能会以为，做出了如此大的牺牲，至少跨端兼容性会很好吧？事实并非如此。各个平台（iOS, Android, 不同的小程序）支持的属性和事件不尽相同。你几乎每写一行代码，都需要去翻阅文档，确认这个功能在目标平台上是否支持。如果不支持，你将面临两个选择：要么放弃这个功能，要么通过复杂的终端判断和替代方案来"曲线救国"。这样写出来的代码，其复杂度和维护成本，甚至还不如为不同平台单独编写两套来得清晰。
在挣扎了两天后，我最终放弃了同时开发小程序版本的想法。
选型思考一： 在评估一个框架时，请优先列出你的核心需求，然后去验证这个框架是否会因为功能限制而阻碍这些需求的实现。
隐性成本二：学习曲线 ------ 文档和资源对新手友好吗？
这里有一个常见的误区：有文档，不等于文档对新手友好。
举个项目中的例子。在使用 webview （相当于内置小型浏览器 可以通过挂载Vue页面来实现原生所不具备的功能）时，我发现从 webview 返回的事件（event）对象，虽然 console.log 能完整打印出其内部所有内容，但我却无法通过 event.detail 读取其属性。官方文档对此问题的描述只有短短一行，几乎没有任何参考价值。
为了解决这个问题，我尝试了定类型、写接口、转语法等各种方案，均以失败告终。最后，我只能采取"隐瞒编译器"的方法：将整个 event 对象强制转换为字符串，然后通过关键词匹配和字符串切割来"提取"我需要的信息。项目就以这种方式跑了十几天，直到后来我偶然在文档的另一个角落，发现官方为这个 event 定义了一个专门的事件类型。
学习资源方面同样匮乏。你在B站搜索"UTS语法"，会发现有且仅有一位UP（还是在我完成项目之后才发布的）出了简短的相关视频，更不用提像 Vue 那样成体系的教学课程了。所有的知识获取，几乎完全依赖于自己逐行阅读和理解官方文档。
一个成熟的技术，其文档会成为你的向导，丰富的社区资源会为你指路。而一个新兴的技术，则需要你自己摸索前行。
选型思考二： 参考自身情况，你是否愿意为探索一门新技术投入大量的时间和精力？
隐性成本三：社区生态 ------ 遇到问题时，有地方求助吗？有轮子可用吗？
这在项目能顺利进行的时候容易被忽视，但一旦遇到问题，就会意识到周围环境有多么贫瘠。
在开发初期，我被 webview 的加载问题卡住了。我能成功加载官方示例中的单文件 HTML，却无法加载我自己用 Vue CLI 打包的多文件网页应用。整个原生端的调用代码只有短短 7 行，逻辑清晰，但我百思不得其解。我将问题发布在官方论坛，十几个小时后才收到一条回复，但即便是这位社区等级很高的热心大佬，也未能给出解决方案。
再比如，当我想在项目里集成一个常用的模态框（Modal）插件时，整个官方插件市场，居然只有两个相关结果，其中一个甚至 0 人下载。面对这样的插件，别说风格是否符合自己的项目，你敢用吗？
诚然，这些基础组件我们可以自己"造轮子"。但当你不想把宝贵的时间浪费在手搓日历选择器这类基础组件上时，你才会发现一个完善的生态系统是多么可贵。一个活跃的社区、丰富的插件生态，是我们在遇到难题时最坚实的后盾。
选型思考三： 如果在开发中遇到棘手问题，社区里是否能快速找到答案？是否有现成的、可靠的"轮子"能帮你节省时间？
写下这段文字，不是为了劝退新手使用某项特定技术，只是希望你在进行技术选型时，暂时忘掉那些 "性能猛兽"、"未来趋势"的耀眼光环 ，回归到项目的本质需求上。
决策：独立开发的"不可能三角"
在编写项目的过程中，你会发现在做技术决策时经常陷入无休止的纠结。
就拿项目里账号的登录功能举例，我是该用 uni-id 这种现成的、封装完美的方案，还是自己手搓一套账户系统呢？
用 uni-id？学一下怎么调用方法就成，实现速度快，用户体验好， 然而它把所有东西都封装好了，我根本不知道它是如何实现的，只知道调用这个或那个方法，我如何通过项目去了解账号的管理方式、token的加密验证？
那手搓一个？原理确实能学到， 但效率极低，并且想实现诸如一键登录的功能，对我一个萌新来说完全不现实，不仅如此，自己写的简单逻辑，安全性也远远不如用uni-id集成的处理方法。
再举个例子，一个大概率不打算上线的项目，为了防范永远不会出现 的简易恶意攻击，要不要浪费几天时间做这些对技术没有一点提升的苦力活------专门给三端（Webview端-Uniapp端-服务器端）通信全部加上大量重复的卫语句，进行所谓的防御性编程呢？
（已经在前端校验过的信息，为了"不信任"原则必须重新校验）
实际上，这种折磨的根源，来自于三种想法的冲突，而我把它们总结为开发中的不可能三角：
- 原理导向：追求的是知其所以然，想把每个技术的底层原理都搞得明明白白。
- 交付导向：追求的是效率和速度，目标就是用最快的方式把功能实现出来。
- 产品导向：追求的是用户体验和程序的健壮性，希望交付一个稳定、好用的产品。
这三种思想虽然大多数时候相辅相成，但是一旦发生冲突就极其难以取舍；如果不对这三者预设一个优先级，你就会像我一样，在遇到这类问题时，陷入无休止的左右脑互搏和精神内耗。影响进度不说，做出取舍之后还难以释怀。
所以，在你新建项目文件夹之前，先问自己一个最核心的问题：
我做这个项目的首要目的是什么？
- 是为了掌握工作技能、准备面试？那交付导向就是第一位的，你要展示的是你快速实现功能的能力。
- 是为了吃透某个框架、学习底层？那原理导向就排第一，哪怕慢一点，效果差一点，也要消化知识。
- 是为了上架运营、给真实用户使用？那产品导向必须是最高优先级，不容置疑。
在项目开始前，狠下心，给它们的重要性排个序。在开发过程中，一旦遇到冲突，就严格按照这个排序来做决策，这能帮你减少至少 90% 的精神内耗！
当然，我这么说，不是让你变成一个极端的人。只看重其中某一种，你可能会成为：
- 只会重复造轮子的理论派
- 知其然不知其所以然的调包侠
- 不切实际的完美主义者
我提供的思路，只是让你确实不得不在某些功能上舍弃掉其中之一时，能有一份快速决策的"指导方案"。
执行：完美的蓝图与现实的碰撞
一个完整的产品，它要面对的，不是安稳的开发环境，而是 无法预测的网络波动、千奇百怪的设备硬件、甚至匪夷所思的用户操作 。这是在我以前开发Web端的demo项目时很难体会到的，无非是注意一下响应式布局，保证大部分情况下布局不会错乱罢了。而真正开发一个能称为产品的全栈项目，以上所有因素你都不得不进行考虑。
举个在移动端项目开发时最容易遇到的问题：设备兼容性。
你们前面看到的这个"四不像"的主页，曾经是一个 充满了各种华丽特效、酷炫动画的3D界面 ，这也是我做这个项目当时最引以为豪、最独特的 "亮点" 。
为了实现它，我专门花了好几天去研究 webview 的搭建和通信。在我电脑的安卓模拟器上，它流畅、优雅，简直完美！
但就在我把安装包打包，发给朋友进行测试的时候，问题来了。
不断出现的闪烁、黑块与卡顿，甚至没有规律可循：有的问题出现在旗舰机而非性能差得多的中端机，所以你甚至没办法推理出它们是因为什么出现；而安卓模拟器哪怕限制它只使用1核CPU与1GB内存，都比那些高性能的手机更稳定，完全无法复现问题。而我手里只有一部手机，想测试问题也无从下手。租个远程真机测试平台？看了一眼价格，100分钟100块，只能是无奈笑笑。
为了保留这个3D界面，我开始疯狂地做减法：砍特效、砍动画、砍元素...... 直到删无可删，中低端机上仍然卡顿。
最后，我只能咬着牙，亲手把这个项目最独特、最亮眼的功能彻底阉割掉：
- 先是把 3D 效果，降级成用数字模拟透视的 2D 效果。
- 发现还是卡，又把 2D 动画继续简化。
- 最后实在没办法，我在设置页专门加了一个性能模式，连最基础的快速翻页动画都换成了渐隐渐显，才算勉强让这个主页不至于成为废稿，但看着最后的"四不像"，只能是有口难言。
（降格2D前最后一刻，此时还保留着开局立牌效果和滑动时的倾斜效果）
而这个主页问题，只是在整个项目实践的意外中某个缩影罢了。你永远不知道，在开发环境外，你的项目究竟会经历何种情况，所以，与其像我一样设计出一个"光鲜亮丽"的外表再不断做减法，你们更应该从一个"原型产品"上不断做加法（实际上就是著名的MVP思想）：
- 先保证存活：优先保证你的核心功能，在信号最差、性能最烂、操作最奇葩的极限情况下，依然能稳定运行。在做项目前看看能不能通过各种方式取得一两部你认为是"最低限度"的设备，在这种设备上先实现最基础的功能；
- 再考虑健壮：为你的应用增加"安全气囊"。你需要预设各种异常流程，比如网络请求失败时的重试机制、用户提交非法数据时的清晰提示、甚至是应用崩溃后的日志记录。一个能优雅地处理错误的应用，远比一个在顺利时表现完美、一遇异常就崩溃的应用要更像一个"产品"。
- 最后追求体验：当你的产品已经能在最差的环境下稳定运行时，再来锦上添花。把你那些酷炫的想法，一层层地加上去。每加一层，都回头看看，它是否对低端设备造成了负担？是否引入了新的不稳定性？这种自下而上的构建方式，能让你清晰地看到每一步优化的成本，从而做出更明智的决策，而不是像我一样，从一开始就陷入对"完美功能"的执念，最终不得不亲手将它摧毁。
这种从"能用"到"好用"的渐进式开发，才是从蓝图跨越到现实最稳妥的桥梁。
心态：独立开发中的心理难关
前面都是在讲方法，也许你在最终做完项目后对这些方法会有更深层的理解与看法，能总结出更适合自己的方法论，但接下来讲的，却是一套套方法所无法解决的问题------心态问题。
第一 数不清的妥协
就像上文3D主页的故事和"字符串切割"方法，这种妥协在整个项目里无处不在： 比如，服务器有限的读写次数限制 ，让我不得不放弃消息的实时推送，改成最原始的用户手动刷新；比如，Uniapp X所不支持的各种事件与属性，让我尝试了一天后放弃了为项目制作一个精美彩蛋动画的想法。
这些妥协，把我脑海里那个完美的、优雅的实现方案，一点一点地踢倒在地。这种感觉，就像一个想画出鸿篇巨作的画家，却被告知只能在巴掌大的纸上用三种颜色作画。这对于习惯了纯前端开发的我来说，是一种巨大的心理落差。
我不知道其他独立开发者是怎么样的，但如果你也体会过这种束手束脚的难受感觉，请一定放平心态，因为你已经知道了，至少有一个人和你感同身受。
第二 看不见的努力
我这个项目总共花了18天，但实际上，后9天的工作，几乎都是"看不见的努力"。
我做了什么？修补各种诡异的bug、优化已经有保底方案的主页性能、给交互加上乐观更新、解耦不同模块的逻辑、抽离公共的样式、统一后端的接口格式......
（从每个组件200多行的通信逻辑中抽离出这段还不到200行的JS代码，专门用于Webview端对Uniapp的通信）
九天前的APP，和现在的APP，从表面看几乎没什么差别 。这种原地踏步的感觉，真的很容易让人气馁，甚至怀疑自己这些天是不是在浪费时间。但请你相信，这些努力恰恰是区分一个玩具Demo和一个可靠产品的关键。如果你也正在经历这个阶段，请一定认识到，这并非原地踏步，而是从"能用"到"好用"的必经之路，是产品健壮性的基石。
第三 无止境的优化
"看不见的努力"的极端，是"追求完美"的陷阱。
每当我完成一部分重构重新审视代码时，总能发现新的bug，总会出现可以优化的地方。我在这样反复重构了几天之后，才终于醒悟：优化是无止境的，完美是一个永远无法抵达的终点。
（没错，30号那天晚上我傻傻的认为项目已经进入尾声了）
一个项目可以永远不"完成"，总有值得改进的地方。所以，你要学会"完成"，而不是追求"完美"。为你的项目设定一个明确的优化期限。一旦超过时间，就勇敢地为它画上一个句号。先发布，再迭代。这不仅是对你个人努力的交代，也是推动项目向前的唯一方式。
收获：代码之外的成长
讲了这么多技术上的坑、决策上的难，你可能会问，既然这么折磨，你到底为啥去做这个项目，这不是自讨没趣吗？
说实话，完成项目之后，你问我是否掌握了Uniapp开发，我只能很遗憾地说"没有"，如果再打一个Uniapp项目，我仍然要一边翻文档一边写代码。
真正能从中收获的，是对"开发"这件事本身，一次彻头彻尾的认知升级。
在这之前，我对前端开发的认知仅限于拿那些常用手脚架搭几个页面，拿后端的文档做好对接而已，至于后端接口的数据结构为什么要设计得那么复杂，产品的需求为什么不停改来改去，我根本就没有关心过。
但当我自己一个人，同时扮演了前端、后端、产品、测试这四个角色后，我才真正理解了他们。
-
我理解了后端：当我看到uniCloud那有限的免费读写次数时，我瞬间明白了为什么后端要那么"抠门"，为什么他们要对数据进行严格的校验和限制。因为服务器的每一个资源，都是真金白银的成本，每一次不必要的数据库查询，都是在烧钱。从那以后，我会在写前端代码时，主动思考如何减少网络请求，如何设计前端缓存，来减轻服务器的压力。
-
我理解了产品：当我为了一个"完美"的3D动效，在各种机型上反复测试、反复碰壁时，我才明白为什么产品经理有时会拒绝我们那些"酷炫"的提议。因为一个产品首先要保证的是稳定和可用，是能覆盖最广大的用户群体，而不是在一个小众的亮点上，牺牲掉大部分用户的体验。
更重要的是，我终于弄明白了那些曾经让我困惑的技术本身 。过去跟着教程做项目，vue-router, pinia, element-plus......这些似乎是Vue开发的"全家桶"，一股脑装上就对了。至于为什么要装？不知道，反正我知道怎么用，所有能用的地方全部改成这些，就能体现出自己 "技术高超" ，实际上是知其然而不知其所以然。
但在这个项目中的Uniapp X部分，这些库全都无法使用，迫使我通过原生方案进行管理，再回头看Vue项目，我开始思考：
- 我真的需要一个路由库吗？
- 我真的需要一个状态管理库吗？
- 我真的需要一个UI组件库吗？
当我开始问这些"为什么"的时候，我才真正开始理解这些工具的本质。它们不是"必需品"，而是一个个为了解决特定问题而生的"工具" 。我学会了从需求出发，去选择最合适的工具，而不是盲目地堆砌技术。
（在删去了一切不必要的组件之后，极其干净的package.json文件）
这，才是我在这18天里所收获的知识，它们对日常的切图写界面可能没什么直接帮助，但我相信它们会在我们的技术路上不断发挥作用------至少我不再是那个只会照着教程敲代码的萌新了。
结语
所以，回到文章开头那个问题：做一个简单的APP，是否真的需要18天？
现在我可以回答：对于一个曾经的我来说，需要。但这18天踩过的坑，让我总结出了文章内可能对大佬来说无关痛痒，但是对于当时的我来说极其重要的宝贵经验。
我写这篇文章，不是为了劝退任何一个想尝试独立开发的新手，恰恰相反，是想把这份避坑地图交给你 。希望它能帮你把这18天，缩短哪怕一个钟头。过程中即使遇到了新的问题，也无需气馁，欢迎你在评论区或私信与我交流，我不是什么高手，只是比你先迈出了半步。