决定动手，就得选家伙什
为什么我要折腾这个什么“艾蜜莉的堕落轮回官网”？说白了，就是最近在家闲得发慌，总不能天天抱着那些老掉牙的技术栈不放。老东家那套东西，我用了五年，早就摸透了，再搞下去也没啥新意。我需要给自己找点事干，逼着自己学点新东西。
去年公司搞了个新项目，逼着我们用Rust写后端API，我搞得焦头烂额。那次踩的坑，让我发誓，下次自己玩，必须选个舒服点、能快速出活的技术栈。不然纯粹就是折磨自己。
趟水摸石头，技术方案先敲定
为了这个“轮回官网”，我花了整整三天研究技术栈。我拒绝了之前用的所有东西，决定全换一遍。就像我上次被老婆撵出书房，跑到阳台工作一样，不破不立。
- 后端：直接拍板用了*，配合Express，简单粗暴，能快速搭起来架子。
- 数据库：敲定用MongoDB，这个项目数据结构变化多，文档数据库改起来方便，不用天天跟Schema较劲。
- 前端：我狠心抛弃了用了多年的Vue，尝试了SvelteKit。虽然社区小，但是编译出来的东西真轻巧。
我把笔记本抱到阳台那个小折叠桌上开始干。阳台的风呼呼地吹，代码经常写着写着思路就断了。我为了强迫自己保持进度，每天定下三个小时，必须搞定一个页面逻辑，不然就不准进屋吹空调。就靠这股拧巴劲，我开始了对“轮回”逻辑的实现。
具体的实现路径：如何让艾蜜莉“堕落”
这个网站的关键点，就在于如何模拟艾蜜莉在不同状态之间的“堕落轮回”。我设计了一个超级简单的状态机，完全是基于用户的每日行为来驱动的。我使用了MongoDB的文档嵌套功能来记录状态历史，方便回溯。
一开始我想得太复杂，又是引入消息队列，又是搞什么事件驱动。结果代码写了两天，发现逻辑上根本跑不通，维护起来一团麻。我赶紧全部推翻重来，用最基础的CRUD逻辑重构了一遍。
我的逻辑非常土，但好用：
- 用户注册，系统分配“初始状态”，记录时间戳。
- 后端设定每日定时任务，检查用户是否完成当日指定的“堕落行为”打卡。
- 如果成功打卡，积分累加，推进到下一层“堕落”状态，推送新的挑战内容。
- 如果失败或漏打卡超过两天，系统触发“轮回机制”——积分直接清零，打回起点，但历史记录保留。
这个逻辑写起来，发现SvelteKit的生命周期钩子真别扭，光是处理那个用户状态的实时更新和页面数据的同步，我就熬了两通宵，差点想直接放弃前端，回去抱Vue的大腿。但转念一想，自己挖的坑，跪着也得爬完。这不光是为了实现功能，更是为了验证SvelteKit到底能不能扛得住稍微复杂点的状态管理。
完工后的心得：舒服才是王道
最终搞定并部署上线，虽然界面粗糙，UI配色辣眼睛，但核心功能跑起来了。我把链接发给几个老伙计瞧了瞧。他们都说网站名太古怪，但承认代码跑得挺流畅，反馈速度比以前Java写的那些Demo快多了。
这回实践我领悟到，技术选型真不能只跟着大流走。自己用得趁手、跑得痛快，才是王道。现在我躺在沙发上，看着阳台那张小桌子，感觉那几个通宵值了。起码，我终于可以心安理得地告诉我老板，为啥非要东拼西凑搞那么多语言：因为有些活儿，单一语言他真干不利索！