如果用一句话概括这一年，大概是：我把大多数时间花在了生活上，却把自己的技术和工作上弄丢了。

但我找到了一个想要一起生活的人，在经历了失去、低谷、重启之后，才开始重新正视“我到底要过怎样的人生”。

p.s.有些事情直到写总结的时候才发现，原来已经过去了这么久，这么快。

老家：远程工作生活​

可能是由于在老家待了太久，有点腻了。

每天对着电脑，几乎没有任何社交；时不时的作息紊乱，昼夜颠倒。好的一点是，每天还能吃到老妈做的饭菜，但那更像是一种被照顾着“活着”，而不是在真正生活。

借着参加技术大会，我给自己安排了一趟江浙沪的旅行（事实是换了个地方酒店住了）。详细见：漫无目的的特种兵式旅行

当时去旅行的感悟如下，现在回看这个任务我还真完成了。

我不敢去想象一个人身处陌生城市、身边没有朋友的感觉。或许，如果身边能有一个人陪着一起旅行，一切都会变得不一样。嗯，看来是时候考虑找个对象了。

旅行让我意识到自己太过渺小，这个世界还有太多我未见识过，未体验过的东西。

十四：第一次真正面对“失去”​

今年年初，我养了一只蓝白猫，它是我花了 1400 买来的，故取名为十四。

它陪了我四个月。那段时间它已然成了我生活的一部分，每次我在电脑前，它都会坐在机箱上，陪在我身旁。它或许不知道我在干嘛，但它只想无时无刻的跟着我。

但在一次误吞异物后，因为我的迟钝愚昧，我未能将它救活。

那几天我几乎是麻木的，自责、懊悔、否定自己。我脑子里一遍遍地回放当时的画面，无论脑海里怎么想，都无法改变结局。

善后是我妈处理的，她不告诉我猫被埋在哪里，还把跟猫咪有关的所有东西都丢了，不愿让我再看到想起。我知道我妈也舍不得，可毕竟我是她的儿子，还要来安慰我。作为过来人，她太明白离别的滋味。

当失去真正发生时，它不会给你任何缓冲的时间，只会直接落在你身上，让你第一次意识到：有些错误，是没有补救机会的；有些陪伴，一旦结束，就再也回不来了。

断联：销声匿迹的一个月​

之后的一段时间，我消失了将近一个月，我把自己”关“在房间里，切断了大多数外界的联系。我企图用游戏来麻痹，用重复和即时反馈来逃避现实，对生活逐渐失去了向往

那种状态我难以用言语形容——不是痛苦，而是什么都不想要了。

醒来、打游戏、再睡去，像是在维持最低限度的存在感。就这样持续了一个月之久，时间在往前走，而我只是被动地活着，仿佛“活着”也不再具备明确的意义。

直到 5 月 3 号的那个晚上。

恋爱：一次极其偶然的开始​

那天是假期的晚上，我和一个大学同学在玩《英雄联盟》大乱斗模式。正好缺人，于是我们在 Wegame 的“人才市场”里随便拉了人。

她就这么“混”了进来。恋爱故事，也是在这样毫不起眼的契机下开始的。

那天晚上我们一路连胜，配合的堪称无与伦比。最终完美下播互加了好友，我当时并没多想，以为也就是一次普通的游戏搭子。

起初她还只是询问我的日常，我略感烦躁不愿搭理。但我能从对话与游戏中明显感到她对我有所好感，我曾一度不愿意恋爱，关系就这样僵持在游戏搭子上。当时的我差点将其拉黑，否则大概就错过她了。

后来才发现，我们都属于那种很聊得来、也很放得开的性格，说话直接，不喜欢拐弯抹角。随着聊天深入，得知她比我大几岁(姐弟恋)，从事硬件开发(我则是软件开发)。白天高强度上班，晚上还能打打游戏，周末还游山玩水的，我是完全看不出有宅女的模样。

我们之间还有太多相似之处：话题、节奏、对很多事情的理解方式，几乎不用刻意寻找共同点。尤其是在《英雄联盟》上。对背景故事和世界观的理解，我们几乎完全对齐。随便提一个英雄，我们基本都能立刻说出 ta 属于哪个地区；听到一句台词，也能马上反应出对应的是哪位英雄。

在一次深夜对话中，我们聊起各自的过去，从生活聊到情感，一直聊到天亮。这种感觉就如同找到了灵魂伴侣一般，我们就这样在一起了。

她后来形容这种默契时说过一句话：“你屁股一撅，我就知道你要放什么屁。”

话糙，但准确。

我开始意识到：我要改变一下现状了。

健身：短暂但真实的自我重启​

当时的我们还只是网恋，我转向镜子看了看我的身材，不由得摇起了头。

我整个家族的基因都是偏瘦型，我也一样，加之我对食物可以说没有任何欲望，常年体重维持在 50kg 徘徊，此时的我甚至只有 47kg。

为了“科学增重”，我开始了健身。

瘦子健身的新手保护期真不是盖的，仅仅 1 个月就从 47kg 干到 55kg，这在我以前是想都不敢想的。

与之对应的”代价“是我一日 6 餐，除去一日正常 3 餐，外加上午茶、下午茶(喝增肌粉)和夜宵。而如果不健身，不去做无氧力量训练，我是无法食入这么多食物的。加上那段时间每天早睡早起，肌肉(体重)就在休息中慢慢长了上来。

我第一次真切地感受到：身体是可以被训练的，人生也是。(习惯的力量)

可健身和学英语一样，难的从来不是开始，而是坚持😣。

深圳：工作与自我焦虑​

8 月 20 日我定了一张从福州到深圳的动车，接着就有了我在深圳 4 个月多的生活，这一块详见：来深圳四个月的生活点滴

来到深圳，一部分原因是为爱奔赴，另一部分原因，则是我想逼自己走出舒适区，真正具备独立生活的能力。从小到大，我几乎一直活在家人的保护之下，很多事情都有人兜底，也正因如此，我对很多现实问题始终缺乏足够的感知。

回过头看，今年我在工作上的表现，确实不称职。我没有拿出 2021 年那种孤注一掷、休学冲刺的状态。当时的我好像只用一个月，就完成了某种“自证”。

而今年，我似乎连开始的力气都没有。老板其实给过我不少机会，也留过余地。只是很多选择，走到最后，还是我自己做出的决定。

那段时间我反复思考一个问题：我到底适合怎样的工作环境？

我始终觉得自己更适合创业型公司，节奏快、责任重、没有太多缓冲空间，但正是这种状态，反而能逼着我往前走，逼着我学习，也逼着我承担结果。相比之下，过于稳定、边界清晰的环境，反而容易让我松懈，甚至逃避。

也让我对自己的性格和状态有了阶段性的认识，如果没有外部压力，也没有清晰目标，我很容易停在原地，对“努力”本身失去感知。

修 bug 我比较在行，但我更需要 fix 我自己。

冻结：X 账号被封​

我今年大部分的感想、分享都放到了 X 上，得知账号被封的那一刻我有点懵逼。意味着以后别人再也无法看到，而我自己自然也无法在原有的账号发表内容。

一开始我试图申诉找回，但是最终无果，我就想那就算了，“不过是一个账号而已。”我当时并不在意。

但冷静下来之后才发现，在互联网世界里，个人 IP 和持续输出，本身就是一种生存方式。而从平台属性和传播效率来看，X 是目前最合适的选择之一。

同时推上也莫名开始兴起一批起号潮，好像一时间所有的人都在 X 创作内容。于是我重新起号，也顺势回顾了一遍自己过去的“起号经历”，一开始只是分享经历、生活，内容也并非精挑细选，真正起作用的是引起共鸣，是我用一种独特的表达方式来呈现。

某种程度上，账号被封也算一次提纯。粉丝少了，围观的人少了，我不再需要顾虑太多目光，我似乎又可以像一开始那样直言不讳，可现在我又不敢了。

不为流量而活，其实也挺好的。

杂项：那些微小却真实的快乐​

游戏机：今年买了 Switch 2，也算是圆了小时候一直想要游戏机的梦。顺便把梦寐以求的《塞尔达：旷野之息》通关了。虽然后期其实玩得有点急，更多像是想尽快结束，好让自己不用再被它分心。

露营：今年去露了一次营，没有什么精致装备，也谈不上多专业，只是把帐篷搭起来，把生活从室内搬到户外。吹着海风，享受着食物，看着天色慢慢变化，在车流高峰到来之前收拾好东西回家。

泡了个温泉： 就只是单纯去泡了个温泉，没想到如此惬意。

出国凭证：今年拿了港澳通行证和护照，意味着我终于拥有了走出去的可能，哪怕暂时还没有明确的计划，但这种“随时可以离开”的感觉，是我之前从未有过的安心。（深圳办证效率是真快，好评）

明年，我想这样活着​

或许如果没有今年恋爱的开始，我仍会迷茫，不知道此刻的自己该何去何从——是否还在逃避现实，是否能真正重获新生。

总的来说，今年对我而言仍然充满了起伏。

我不得不承认： 我依旧很难权衡工作与爱情，有时像是一个被爱冲昏头脑的人。

她常说，我总是把未来幻想得很美好，但行动总是慢半拍。

明年，我希望自己能做几件具体的事：

• 给自己更多独处和学习的时间
• 重拾健身计划，让身体和精神都更有力量
• 补上“哑巴英语”，她要考雅思，我也不能太拉
• 找到一个可持续的收入来源，给生活更多安全感

今年，有人陪我一起过年了。

想给这段时间做一个稍微完整一点的记录。与其说是讲故事，不如说是整理这几个月里生活感受上的变化——不会事无巨细地还原来龙去脉，只记录那些真实发生在我身上的状态转变。

从为爱奔赴来到深圳→开始一段全新的生活→到远程工作离职→再到接触合约交易、经历爆仓→X 账号被封→带对象回老家参加亲戚婚礼。

这篇文章其实上个月就已经在脑子里打过草稿，却一直拖到现在。很多具体的事情，或许之后还会单独写成几篇慢慢展开，但至少现在，想先给当下留下一份备份。

也算是，给这四个月一个暂时的落点。

一、来深圳——为爱奔赴​

去年一毕业就顺从「家里人的安排」下在福州生活，后来因为远程工作，又回到老家的县城待了半年多。那段时间谈不上好或坏，只是节奏稳定、路径清晰，一切都在既定轨道上往前走。而我家的猫因为我的愚昧而逝世。那件事发生之后，我很长一段时间都没缓过来。不是那种歇斯底里的难过，而是一种持续的、钝钝的自责，迟迟无法走出。

就这样在老家整天沉迷游戏，直到一次游戏中遇到我现在的对象。起初只是很随意的交流，从游戏里的配合，到语音里的闲聊，再到慢慢延伸到生活本身。我发现我们出奇地聊得来，无论是三观还是兴趣，都有着难得的契合感。那种感觉很难形容，好像我们就是天生一对！

于是我开始谈恋爱并网恋奔现。第一次来到她所在的城市，我们一起坐上了「湾区之光」摩天轮，开始续写我与她的故事。

当然，事情并不总是一帆风顺。 在一次分别之后，我们因为一些不和分开了一个月。但好在，最终我们还是选择了彼此，重新走到了一起。

复合后不久，我便搬到了深圳，也真正开始了这段恋爱生活。

二、生活环境与消费​

这次选择来到深圳，算是我人生第一次真正意义上的「自我安排」：一个人离开原本熟悉的城市，脱离家人视线与既有环境，重新开始一套属于自己的生活节奏。

关于租房，我先把预算和基本要求告诉了对象，她提前帮我跑了几家中介，筛选了几个房源让我选。最终定下的是一套离她家大概 200 米左右的公寓，租期半年。这也意味着，只要时间允许，接下来的生活里我们几乎可以天天见面。

在正式入住前，我提前在网购平台买了一些生活用品和基础家居，等房子一交付，就一点点布置起来。当所有东西就位，有了一个可以安心睡觉、可以摊开电脑工作的地方之后，我突然意识到—— 其实生活的“形态”，和我之前并没有本质区别。同样是一张桌子、一把椅子、一台电脑。

消费上，明显能感觉到自己“添置了不少新东西”：

• Switch 2
• Go Ultra 运动相机
• 投影仪
• 电动车
• 以及一些乱七八糟的小物件

饮食上，早上麦当劳，中午快餐外卖，晚上和对象去吃堂食（有一段时间去她家吃她妈做的饭菜）。

直到每个月交房租的那几天，这些消费才会以一种非常现实的方式提醒我：在深圳生活，成本并不低。

尤其是在两个人的生活模式下，“买给我们”的界限常常会变得模糊。一顿饭、一次出行、一个看似顺手的小决定，钱就这样在不经意间慢慢流走。

再加上一些冲动消费，让我对「理财」这件事的感受也慢慢变了。(见后文)

三、恋爱的滋味​

我原本是那种很习惯独来独往的人。

一个人待着不会觉得无聊，反而有点享受 Alone 的状态：自己吃饭、自己走路、自己消磨时间，不需要解释，也不需要配合。

但自从有了对象之后，生活里开始频繁出现“我们”这个词。 一起吃饭、一起逛街、一起出门遛狗散步、一起吐槽每天发生的琐事—— 明明都是些再普通不过的日常，却总能聊出一堆废话，而且怎么都讲不完。

恋爱不到半年，我们却已经一起经历了很多事，其中不少都被我零零散散地记录在 X 上。回头看才发现，这段关系里充满了幸福。

• 一起加入了网易云双人空间开始一起听
• 创建了 iCloud 的”家庭共享”，并将当前的片刻放在共享相簿里
• 双方都给对方开通了微信的亲属卡
• 一起去海边露营，吹海风
• 给她注册了一个域名——[她英雄联盟 ID].lol
• 去她家吃她妈妈亲手做的晚饭。
• 带她一起回老家参加我表哥的婚礼
• ……

这些事情单独拿出来看，其实都不算多么特别。 可当它们被串联在一起的时候，就变成了一种只属于我们的轨迹。

当然，恋爱并不全是甜的。

恋爱时的大部分行为就不能自作主张了，而我偏偏又是那种习惯凭感觉做决定的人。有一次我们吵架，她说我经常临时更改计划，却很少提前和她商量，也没有真正站在她的角度考虑问题。那一刻我才意识到，自己某些看似“随性”的行为，本质上其实挺自私的。

恋爱带给我最明显的变化之一，是属于自己的时间变少了。也可能是因为还处在热恋期，我们几乎天天约会、吃饭、见面。有时候我甚至会想：要是我真的是时间管理大师就好了(bushi)

钱包的变化倒没有那么强烈的痛感，但数字确实在一点点变少。不过快乐也是真的、很具体地在心里发生着。某种程度上来说，钱确实可以买到快乐。

**恋爱也让我变得更加难以专注。**有时候为了秒回对象的一条消息，就会不自觉地分神；我又不太愿意开勿扰模式，生怕错过什么。甚至偶尔刚进入心流状态，就被一条消息拉了出来。

果然，女人只会影响我写代码的速度。（🐶保命）

但即便如此，心里有一个人可以挂念，同时也被人挂念着，这种感觉本身，还是很幸福的。

四、远程工作离职​

10 月中旬，我从上一份远程工作中离职了。 不少人对此感到困惑——薪资不低、学习资源充足，工作内容也谈不上完全无法胜任。说实话，连我自己也曾反复问过这个问题。 那是一家初创公司，老板并非技术出身。技术选型往往来源于他的调研结果、个人偏好，以及社区里的风向反馈。对技术人员来说，这意味着你不仅要把事情做完，还要反复解释、沟通和说服：为什么不用某个框架、为什么这样设计更合理、替代方案又是什么。

项目没有明确的 KPI，也几乎没有严格的交付期限（当然，有些任务本身确实难以精确预估）。会议节奏也相对随意：有时因为老板临时有事而推迟，有时甚至直接顺延到第二天。表面看起来相当松弛，但人往往会在这种环境中，悄无声息地滋生惰性。

理论上，这样的模式并非不可行，但前提是团队成员必须具备极强的自我驱动力。缺乏外部约束的情况下，这种状态其实很难长期维持。团队需要的是高度自律，而不是网传的那种“随心所欲的自由”。

而现实中的对应却是：每一次周会，分享的内容看起来不少，讨论也算热烈，但项目本身始终没有实质性的推进。那种“好像很忙，却什么都没真正完成”的感觉，逐渐变得无法忽视。团队更在意的是有没有参与讨论、有没有在会议中碰撞出想法，而不是事情最终是否真的被做好。整个节奏像是“不急不躁、慢工出细活”，但久而久之，却让人看不到明确的方向和结果。

从工作当中，我也逐渐意识到，我并不擅长、也并不享受“说服他人”这件事。加之我本身算不上自律，尤其在编码和工作时间上极不规律——更多是靠灵感驱动，来了就一股脑儿输出，没来时效率几乎为零。

再后来，我发现自己已经不再像刚入职时那样投入。对工作的厌恶感慢慢滋生，拖延、逃避也随之出现。

尤其是在远程、没有人真正盯着你的情况下，我很清楚地意识到一件事：我在混。

不是能力不足，而是缺乏那种被推动、被逼着往前走的状态。

最终真正触发离职的，是国庆第一天（那天仍是工作日）。我白天和对象出去玩，却没有提前报备请假，被老板指出了问题。老板说得并没有错——一个人的下意识行为、选择和态度，往往比语言本身更诚实。

于是，我做出了离职的决定。（下方为当时的聊天记录）

尽管如此，我依然感谢这段经历。给了我一次工作机会，也让我更早看清了一些并不适合自己的东西。

至少有件事现在是确定的：事业与亲密关系之间，很难在短时间内做到真正兼得。

至于未来要怎么走，是否重新选择上班、重新磨炼自己——说实话，我暂时还给不出一个明确的答案。

五、沉迷合约交易​

在我离职期间，正好经历了 1011 黑天鹤爆跌，我是这时候才开始正式留意币圈（虽然之前已经创建过账号了）。最初只是抱着“试试”的心态，接触加密货币和区块链开发。后来无意间刷到一篇推文，一时兴起，便开始照着模仿。

我先从刷空投开始，主要是一些 Alpha 项目。你可以简单理解为：项目方通过“免费发币”来拉新、做宣传，而用户则需要通过刷交易量、交互成本来换取资格。实际收益并不高，确实只能赚点饭钱。

随着对交易所的使用逐渐熟悉，我开始注意到“合约”这个东西。起初并没有急着下场——说白了，我根本不懂交易，看不懂 K 线，也不了解消息面。但币圈的故事总是极端：有人一夜暴富，也有人一夜归零。尤其是 10·11 之后，这样的消息不断涌入视野。

对该“玩法”的介绍，推荐你观看该视频 从天堂到天台，为什么币圈总在爆仓？

起初，我将一部分资金转入了合约账户，另一部分则留在现货里，用来继续刷 Alpha 积分。我严格遵循着低仓位，低杠杆，行情一走对，我便尝到了久违的“甜口”，账户数字稳步上扬，但我看着账户里那点并不惊艳的收益。于是，“试试加一点仓位”这个念头悄悄冒了出来。再然后是“稍微提点杠杆也没事”。很快，我已经从“试试”进化到了“再来一单”。

就这样交易频率开始失控，开仓、平仓、反手、再反手，就在我自我感觉良好、小有成就的时候。那天凌晨 3 点鲍威尔讲话来了，我不记得他那时开头讲的是 Good afternoon 还是 Hello everyone，只记得那时我选择做多，几秒之内，一根 K 线直插而下。盈利瞬间变成亏损，而且还在不断扩大。

我没有设置止损，只能眼睁睁地看着余额一点一点减少，仿佛在看一支正在缓慢放血的股票——每一秒都在掉血，每一秒都舍不得卖。

在某个瞬间，我选择割肉离场。事后证明，这是个正确的决定，行情随后跌得更猛。这是我第一次正面感受到这种级别的市场冲击，也是在那一刻，我开始恐慌，不敢轻易操作，选择观望，此前我从未经历过这种级别的行情冲击，没想到第一次，就来得如此刺激、如此直接。

这时我还没意识到这个市场**远比我想象的要残酷得多。**而这次没有爆仓，命运似乎要给我一个更深刻的教训。

那天之后，我整个人好像进入了一种奇怪的状态。开始复盘，要是我当时手速快一点平仓然后反手梭哈做空，会不会已经让我的本金翻倍。我开始学习所谓的“正确交易”：止损、止盈、仓位管理。

可随后的行情远比我想象的还要残酷，眼睁睁看着 BTC 从 107000 一路跌到 80000 出头，没有暴跌，没有黑天鹅，只是温水煮青蛙般的下行。这期间不断被打损，一开始所赚取的盈利一点点吐回出去。

这时的我已经开始有些急了，纪律开始松动。中间有几次明明达到了止损位，可我却不甘心就这样亏损，幻想着能够涨回去，就一直处于“套牢”，最后要么博一个回调卖了，要么下跌狠了直接割肉。这时的我开始失去了纪律，并没有严格执行策略，同时心想着要快点做一单赶快回本，就这样时不时盯盘寻找机会。

与此同时手上的筹码并不多了，一个更危险的念头出现在我的脑海里——我把原本用于现货定投和刷 Alpha 的资金，全部转进了合约账户。

赌徒心理，彻底接管了我。此刻我的内心只想着回本。

11 月 21 日，BTC 探到 86000。那一刻我没有狂喜，只是松了一口气。随后出现反弹，账户曲线再次抬头。我开始变得“谨慎”，却又“犹豫”中错失机会。脑海里全是 “当时要是开仓多好”，就这样我又开始重新相信感觉。不再完全依赖止损，而是“灵活处理”；不再严格执行计划，而是“根据盘面优化”；每一次破坏纪律，都能找到一个听起来很专业的理由。

可账户已经不允许我再慢慢等了。行情稍微一动，心跳就开始加速。我发现自己已经不是在交易，而是在赌、在守——赌一根迟迟不来的反弹，守一段只存在于想象中的希望。

就这样我本以为行情会慢慢好起来，直到 12 月 1 日，一次极端波动，彻底终结了我的账户。

我原本是有止损的，在那个点位，我本应果断离场。但就在最后一刻，我亲手把止损撤掉了。抱着一点点侥幸心理，妄想着硬撑到死。结果毫无悬念：仓位没了，撑不到第二天“迟到”的超跌大反弹。

我盯着清空的账户发了很久的呆，没有愤怒，也没有不甘，更多的是一种迟来的疲惫。我甚至不敢再做任何操作。不是因为没钱，而是因为我已经分不清——我再充进去的每一分钱，究竟是在参与交易，还是在给自己的侥幸续命。

冷静下来后，我反而庆幸这次爆仓。它像一记重锤，把我从麻木和幻想中敲醒——让我终于脱离那条不断刷新、却早已失真的资金曲线，脱离对每一根 K 线的过度解读，脱离把情绪寄托在价格涨跌上的生活。

当我把这段经历写下来、拆解、复盘，我开始看清一些此前刻意回避的问题：

• 我早已被困在币圈的信息茧房里
• 耐心被不断消耗，心态越来越浮躁
• 很多“策略”，本质上只是情绪决策
• 而最致命的，是我正在失去独立思考的能力

每天醒来第一件事是看账户，睡前最后一件事也是看账户；隔一会儿就点进去刷一眼净值变化，盯着 K 线，看点位、等消息、猜讲话、纠结要不要挂一单。

表面上看，我好像在“认真交易、认真研究行情”，可回头一看，很多时候我什么正事都没做成。一天结束，除了情绪的反复拉扯，几乎没有任何真正沉淀下来的东西。

健身计划被打断，生活作息被打乱，注意力被彻底撕碎。这其中或许也夹杂着我内心深处懒惰成性的借口。

而最关键的是，我正在一点点失去独立思考的能力。不是因为我有多懂交易，也不是因为我足够理性，而是我在一个自己并不真正理解、也完全没准备好的领域里，用真金白银去赌情绪。

但无论如何，这段经历至少让我清楚地看到了一件事——当一个人把全部精力都交给市场时，失去的往往不是钱，而是学习能力、生活节奏，以及对自己的掌控感。

这不是一个关于亏损的故事，而是一段关于失控的记录。

六、推特被封​

12 月 11 号的早上 9 点，我还在像往常一样刷着推特，顺手把一则推文通过私信分享给对象。那时一切都很正常，时间线在刷新，仿佛世界从未停转。直到 10 点整，我的邮箱弹出了一封通知。是一封来自 X 的官方邮件——由于违反 X 规则，你的账号已被举报并被冻结。

我盯着那行字看了很久。第一反应并不是愤怒，而是困惑：我违反了什么规则？

我没有发过极端言论，也没做过垃圾广告，更谈不上引战。账号里大多数内容，不过是生活类的分享，个人吐槽，甚至连“输出观点”都算不上。

隔了一会儿，我才发现事情并不只是发生在我一个人身上。时间线里开始陆续出现各种**“账号没了”**的截图，

有人还在调侃，有人已经开始骂平台，也有人冷静地统计着被封账号的共同点。我则开始复盘自己最近的行为，并把这些猜测整理后，发布在新创建的小号上。

这件事让我不由得想起本人 2019 年4-5月的一次经历。那年正值 QQ 的封号潮，我作为某个群的群主，因为群成员发布了违规内容，整个群连同我的账号一起被冻结。那也是我后来再也不愿意当群主的原因。

或许正因为有过类似的经历，如今再面对一个社交平台上的永久封号，情绪反倒没有想象中那么剧烈。震惊有之，遗憾有之，但更多的，竟是一种近乎麻木的熟悉感。好像这类事情，早就被我在心里预演过不止一次。

不过换个角度想，也未必全是坏事。

账号清零之后，我反而重新回到了一个无需顾虑粉丝、不必迎合算法的状态。 我本来就是为了记录而写， 而不是为了被看见才记录。

只是可惜的是，到了 2025 年，我才发现自己在推特上留下了那么多零散的文字、思考与片段，如今却只能自己查看，像被锁进了一个只对我开放的旧抽屉。（我会考虑做爬取我账号的信息做成一个归档页）

我又回头看了一眼自己的 blog——那个真正意义上归属权完全在我手里的地方。才发现今天的大多数记录，都被我习惯性地碎片化丢进了推特的时间线里；而自己的 blog，这一年却只更新了寥寥两篇。

未来我要养成在 Apple Note 上编写推文，然后在发布到 X 上的习惯，这样有助于我归档，以及防止类似的事情再次发生。

这次封号与其说是失去，不如说是一种提醒。提醒我该把笔重新拿回自己手里，把那些原本就该沉淀下来的文字，安放在一个不会被随时清空的地方。

或许，这才是我真正该回去的地方。

七、带对象回老家参加表哥婚礼​

12 月中旬，我原本计划带着对象回老家参加表哥的婚礼，也算是第一次正式把她带进我的家庭与亲戚的视野里。不过婚礼安排在周三，而她当天下午还有一场英语演讲比赛，时间上实在无法兼顾，最终决定我周一回去，她在周四中午再抵达老家。

我准备了一束花去接她，也是我第一次送真花给她(上次送的是积木花)。

在我那地方的风俗，女方第一次来到男方的家里长辈是要给见面礼的，于是我爸妈就带着她去金店挑选了一款手链给她。我的老家以海鲜出名，于是那几天的生活几乎被海鲜排挡承包，我和她甚至一起吃出了肚子轻微痉挛的感觉。

我们还一起去夹娃娃、泡温泉。从她的表情上我不难看出，她对我的老家很满意。今年护照还到了，或许下一次记录的，就是我们第一次一起出国旅行了。

嗯，就先写到这里吧。

这一年也快要结束了，至于未来的打算，等到年终，再好好梳理也不迟。

不过感觉这篇幅就像是 2025 年终总结了。。。

办证​

其实我一开始并没那么想去办理港澳通行证。在此之前我一共去了3次出入境大厅，都不予通过，给我内心造成了不小的打击，心里总担心下一次还是同样的结果。

就在月初，我对象计划去香港（是的，我有对象了），问我是否同行。我说自己连港澳通行证都没有。她告诉我深圳办理很快就能拿到，还安慰我说："凡事往最坏处想，结果才能更容易接受。就算失败也无妨，万一成功了就是惊喜。"

于是我抱着"死马当活马医"的心态，又一次尝试港澳通行证申请。

果不其然，办证人员询问我上次办理为什么不予通过(有申请记录)，我简单叙述了下，他也没过问，由于我是外省户口，因此她还需要给我户口所在地发个回执核实下真实情况。

尽管等待的几天去查看办理进度时我还是胆颤心惊，但好在看到“制证中”我悬着的心终于落下了

也确实正如我对象所说，深圳办证无比高效，8天后收到由广州发来的 EMS 邮件，看到证件的那一刻我无比开心，终于可以去香港了😭

赴港​

过海关​

在去往香港前，需要在营业厅软件开通漫游功能用于接收短信的，并购买境外流量套餐，同时手机 SIM 卡设置开启数据漫游，这样当你抵达香港时，信号显示 CMHK 时便可连上网络。

一早乘坐深圳北(起始站)抵达香港西九龙站(终点站)，全程不到 20 分钟，跟着人流抵达口岸，掏出港澳通行证来到自助通关闸机准备出境，当我放上我的通行证，机器提示我需要走人工通道，此时我看着对象已经穿过闸机，我又望向早已排满队列的人工通道，我心不由得凉了一截。跟对象说明了完情况后，便跑向人工通道开始排队，大约等待了 20 分钟，将证件递交给边检人员，她看了眼电脑屏幕，转头便询问起我来。

边检人员：此行的目的？

我：陪对象去香港玩。

边检人员：待多久？

我：当晚回。

边检人员：返程的车票买了吗？

我：还没，不确认待到什么时候。

边检人员：做什么工作的？有没有工作群？

我：有的，兄弟，有的。(我将手机递给他看，并把与对象的聊天记录给她看）

边检人员：（稍微翻了翻我的手机，也没再过问，便放我过去）

我斗胆猜测我的证件是因为我的户口是高危地区导致无法通过自助闸机。

成功出境后，我顺着人流穿过长长的过境通道，很快抵达香港入境边检处。在这里，我再次看到熟悉的自助通关闸机。这次总算是体验了完整了操作流程：先刷一下港澳通行证通过第一道闸门，然后在中间区域按压指纹，随后便可通过第二道闸门拿到过关小票便可正式入境香港。

出入境过程总结：内地出境边检 ➝ 内地海关 ➝ 香港入境边检 ➝ 香港海关 ➝ 入境香港

邪修出入境：问妈祖

开港卡​

此行对我而言的目的很明确，就是线上开户港卡（汇丰，中银，众安）。 到了香港后，已经是午饭点了，在商场选了一家餐厅坐下，与对象的朋友会面，吃了顿铁板牛肉饭(72 港币=66人民币)。如果在深圳吃的同类别的食物，其实也没贵很多。

连上商场Wi-Fi，打开事先下载好的银行App，开始填写资料、上传出入境记录和通行证照片。全程不到 1 小时内，便完成了 3 张卡的开户，除了汇丰没有直接开通账户还需等待审核，中银与众安都是直接可以登录 app 了，之后在 app 上操作等待实体卡发件到大陆即可。

有了港卡后，至少资金跨境消费与支付可以省下一大笔的手续费，至于出金与投资这些都是基本操作了。不过手头还没有护照，还是有很多我想搞的账户是无法开通的，不过我想距离有护照以及第一次出国应该也不远了。

关于如何开港卡，外面的攻略多的数不清，这里就不在过多叙述细节，最终还是得根据自己的实际情况来操作。

逛逛街​

因为有人带，我只需要一路跟进即可，饭后我便化身为工具人，一个无情的背包提货机器，陪对象及她的朋友去了趟铜锣湾的商圈逛了逛，扛着一大袋物品走了一下午。

在逛街的过程中，我注意到香港街头的药店数量特别多，其中不乏一些真假难辨的店铺。店内大多售卖跌打油等药油，以及各类保健品，并且抢购的人还不少。尤其是下图这款药，火的离谱。很多大陆人都来香港买这个带回去。

离港​

深圳去香港就是方便，当天去当天回，基本不用担忧车票余量。离港可就没赴港那么有”阻碍”，回去容易出来难。

也不知道下次去香港又会是何时，香港麦当劳还没吃，1000 元一晚的小小间的香港酒店还没住，不过在那之前，先把签注续上吧。（已经开始期待下一次香港行程了）

感受​

由于此行比较匆忙，没有太多时间去感受香港这座城市，只能说是走马观花般的体验了一下，也算是领略了别一番的异域风情。

不过对我而言，这次去香港从心理上移除了我某须有的罪名。回想 23 年的夏天第一次去出入境办理港澳通行证被告知有”不良”记录不予出境，到 24 年夏天才得知该不良记录竟是”电诈“，于是尝试与工作人员解释事情的来龙去脉，总算给我提交到审查系统中。但又因我处在偷渡涉诈的高危地区(福建)，最终在核实阶段被公安人员告知我提供终止审查书才肯给我办理。

或许是我的不懈坚持打动了办证人员，才有的此次香港之行。

回顾整个旅程，说得好听些，倒像是一场特种兵式的旅行；说得不好听，则是漫无目的、四处奔波的流浪。我对旅行的想象过于简单，竟没能真正放下心来，细细体味每座城市独有的人文风情。

这段旅程也让我意识到，旅行的意义不只是到此一游的打卡，更是在陌生中与自己对话，在不确定里发现生活的丰富与可能。每一段匆忙的脚步背后，都隐藏着成长的印记和内心的蜕变。

旅行地图​

第一站：杭州(3.6~3.10)​

借着参加杭州 D2 终端技术大会，让我有机会去杭州游玩的一番，来到西湖边上四处闲逛，发现了一个可以乘船游湖的项目，于是花了 50 块体验了悠然自得的水上时光。

或许是初到陌生城市的不适感作祟，让我早早结束了西湖之行，下船后随意找了家最近的霸王茶姬，独自漫步在回酒店的路上。耳机里放着熟悉的旋律，我却早已走神，不知自己在思索些什么。直到夜晚，一位朋友的消息打破了这份孤独的氛围，才让我从发散的思绪中抽离出来。

来杭州的第二天，便开启了面基推友、组局吃饭的流程。原本只是几个人的小聚，不知怎么人越拉越多，最后竟发展成了一场 15 人的大型饭局。连农村吃席都未必能凑出这么一桌人，那场面我就不放图了，自己脑补一下吧。

倒是从聊天中得知，许多大厂人基本都是晚上 9 点后才下班——听着都让人窒息。我很难想象，长此以往，那些被压缩的时间和生活感，会从一个人身上悄悄剥落掉多少东西。每天两点一线，久而久之，也就只剩下一条疲惫的轨迹。

饭罢，归舍，盼明日。

D2 大会举办地设在阿里巴巴的园区，场地真的气派非凡，最让我印象深刻的画面是“程序员的三种活法”。我忍不住自嘲：25 岁的我啊，只想活着（言外之意——躺平）

第二天，我和一同来杭州的朋友一大早骑着单车去了西溪湿地。清晨的空气中弥漫着大自然的清香，让人神清气爽，整个人也轻松了不少。中午顺路去了趟山姆超市，在山姆餐厅吃了传说中的牛肉卷，味道还不错。也是这次才知道，原来山姆需要会员（260 元/年）才能进，好在朋友人脉在线，借到了一张只能消费一次的山姆体验卡。进去转了一圈，最后只买了一包咖啡豆就出来了。

都说杭州是个美食荒漠，但对于体重不到 100 斤、对美食无欲的我而言，却没有任何感知。如果考虑换一座城市生活，杭州似乎是个不错的选择。

第二站：绍兴(3.11~3.12)​

带着随性闲逛江浙沪的心态，恰巧在网上认识了一位来自绍兴的老板，于是约好时间，从杭州东站搭乘不到半小时的动车前往绍兴。有人作陪的旅行与独自上路截然不同，那份原本的不安感也在交谈中悄然消散。

说来惭愧，起初听到“绍兴”这个名字，我脑海中竟一时想不出有什么与之相关的印象，直到在地图上看到“鲁迅故里”地铁站，才恍然意识到鲁迅原来是绍兴人。于是便去参观了鲁迅故居，亲身体验了《从百草园到三味书屋》的情境，那段从家后菜园“百草园”走到前面私塾“三味书屋”的童年故事仿佛鲜活地展现在眼前🤣。而这处占地颇广的老宅，竟真的是他家的故居，才意识到鲁迅真出身于当时的大家族——这便是老时的大户人家了。

想着来都来了，总该带点什么纪念，于是被 30 块的冰箱贴狠狠地收割了一波。

原以为绍兴除了鲁迅并无太多可说，直到从这位老板朋友口中得知，绍兴居民的人均可支配收入竟在浙江省名列第一，才让我大为惊讶。由此也深刻意识到，对一座城市的了解，不能只凭刻板印象，还得听听当地人的现身说法，才能窥见它更真实、更丰富的一面。

拖这位老板的福，吃了几顿大餐，顺带去做了个推拿和拔罐，师傅说我湿气很重，看样子要少喝冰饮，多喝奶茶。

在朋友的款待下，这趟绍兴之旅显得格外轻松惬意。

第三站：上海(3.13~3.14)​

高楼林立的冲击是上海给我的震撼，外滩给了我一场视觉的盛宴。短短两天，根本无法看尽上海的全貌。但它给我留下的震撼感却久久不能散去。作为从农村出身的我，我第一次真切地感受到，什么叫做“城市的高度决定了你的眼界”。

东方明珠	陆家嘴三件套

走着走着发现有个观光隧道可以直达陆家嘴，于是花了 90 块钱买了张门票，我的评价是一坨🤡。

借着在字节工作朋友的访客，成功去大厂吃了份员工餐！第二天还去了趟美团园区吃了顿外卖（说笑的

字节访客卡	美团访客卡

上海没敢多待，城市的节奏快得让人喘不过气。站在高楼林立之间，会让我感受到一种前所未有的渺小与冲击。只有真正置身其中时，才发现很多东西不是靠想象就能理解的。

第四站：苏州(3.15)​

从上海虹桥到苏州园区只用不到 30 分时间，与网友约好在苏州中心商城的咖啡局，在湖西观望了金鸡湖的，畅谈了双方各自的故事，相比之下我的经历还是有些过于平庸了。

就当我准备聆听漫步回家时，发现我的右耳机掉了，好在有苹果的查找，让我成功找寻遗失的耳机，又一个爱上苹果的理由了。

晚上与一位亲戚一同吃了下饭，顺便带我逛逛了苏州的街道，让我诧异的是街道的人员如此稀少，一开始我以为是阴雨天气导致的，于是我多嘴吐槽了一下，才得知原来苏州竟然没有夜生活，8 点之后大多数的店面都不营业了，他还和我说江南地区绝大多数的城市都这样（回想所去过的绍兴也是如此），生活节奏比较慢，家庭观念较重，小孩从小到大晚上都不出门，就导致这样的现象。或许这也是为什么苏州能被称之为适合宜居的城市之一。

受天气的影响，这几天在上海和苏州的体验并没有多好，回到酒店我便不由得开始想家(此时的我已经离家有 10 天了，一般旅游心理边际效应递减期是7天)，连续多天都独自一人住酒店孤独感在此时莫名的压抑😞，辗转反侧之余便定下了第二天下午回去的班次。

第二天一早去了苏州知名景点平江路，江南风情瞬间映入我的眼帘。小桥流水，仿佛置身于古画之中。街道两旁的古色古香的民居与店铺，与这片氤氲着历史气息的街景相得益彰。

从平江路一路向北，偶然看到茶颜悦色的门店，不由自主的开始排队(近半小时)，原来想要喝上它还需预点单，现场排队取茶，甚至不能外卖，只能现场饮用，不得不说味道是值得等待的。

走完平江路准备来到苏州博物馆时想要进入参观，被告知要提前预约才能够进入，一看预约单只能排到下周了（这就是不做攻略的代价🤡）

事已至此，不如提早抵达车站，乘坐回家的动车。到了车站之后，竟开始犹豫不决，过早的结束旅途似乎没给这段路程画个完美的句号。正当我在候车大厅踌躇时，一位苏州的网友发来消息：EDC China 电音节将于 3 月 22 日在苏州举办（此时是 3 月 16 日），而我又恰好是个电音迷。

抱着来都来了的心态。于是原本等待检票的我，在最后一刻取消了回程班次，改而临时搭上前往无锡的列车，给旅程续写一个意料之外的番外篇。

第五站：无锡(3.16)​

因为看过西湖，莫名的对湖有一种好感，从地图上看到了太湖的广大，于是约了位推友一同去了无锡贡湖湾彩虹步道，赏目太湖。

原本计划前往灵山胜境参拜灵山大佛，但受限于时间安排，只得作罢。恰好我有位发小在常州，于是无锡只停留了一天，便匆匆启程前往下一站。

第六站：常州(3.17-3.18)​

一直住朋友家里边，基本没去玩什么，我对这座城市的评价请看下图

此时的我才发现我其实不是在旅居，而是特种兵式旅行，毫无目的性随处逛逛的那种，只要有局我便随叫随到。以至于我几乎待了1-2天便换一个地方住，此时对于旅游本身关注点已经不在玩上了，本打算去南京的计划，但人生地不熟的， 也不知道去了能做什么，与其来回折腾自己，不如计划取消。

第七站：重返苏州(3.21-3.23)​

这次有了上次来苏州的经历，于是我提早预约了苏博的门票，带着没体验过博物馆的心态稍加浏览，不过我对博物馆内的展品并无兴趣，这里就一笔带过。

下午便和一同去 EDC 的朋友会面，晚上在金鸡湖(湖东)观望着对岸，以不同的视角看，好天气对旅行的体验感提升是巨大的。

不过这次的主题是听。当晚我们怀着激动的心情花了 40 分钟连骑带走来到 EDC 的会场，可惜非工作人员无法进入，但光是远远听着试音的部分，就已经让我们这些电音迷血脉偾张、热血沸腾。

第二天提早 1 小时来到会场，远远就能听到音浪从场馆深处一层层传出来。入场后，那股扑面而来的低音震得胸口发麻，耳朵在轰鸣中也逐渐适应了电音的节奏。只见得他们摇起来，我的身体便不由得跟着节奏开始动了起来。或者这就是电音的魔力吧——无需言语，无需默契，只要一拍即合的节奏，就能让所有人瞬间连接在一起。

此刻，现实的琐碎和压力全被抛到脑后，只有音乐、节奏，还有那个不愿停下的自己。当晚回程的路上，我们虽然疲惫，却像刚完成一场灵魂的洗礼。那一晚，我们不是观众，是参与者，是舞台的一部分，是电音世界的信徒。

最后与这位朋友离别的时候，还顺走了一只秋田犬。

最终站：家(3.24)​

这一段不想多写，每当想起都会一时语塞，不禁落泪😭

经验分享​

攻略​

我这个人更倾向于随机应变而非通盘计划，不擅长提前制定行程，更喜欢享受当下的过程，并在事后回顾总结。如果这时有人带我玩、我只需掏钱，那我大概率会屁颠屁颠地跟着走。

因此我很不喜欢做攻略，地图就是我的小攻略。“说走就走的旅行”，是我对“自由”最直接的兑现。

但现实是，漫无目的的游玩会大幅降低旅行体验，尤其是你抵达目的地却发现需要提前预约的时候。代码调试都要踩坑，更何况生活。

酒店​

我几乎没什么订房经验(这是不是暴露了什么)，在此之前都是在美团订的单，从不看装修时间，只看距离，而这就导致十分容易住上一些体验非常糟糕的房间，结果往往踩坑——比如设施老旧、条件差等问题，缺乏统一标准。

后来我接触到了华住旗下的汉庭酒店，体验远胜一般民宿或小旅馆。

说个真实的烦心事：我在杭州西湖的第一晚，住的是美团上订的 283 元酒店，入住时被收了 300 元押金，还让我签反诈承诺书。我还花钱升级了所谓“高级大床房”，结果房间跟普通房毫无差别，体验极差。

而入住华住系酒店就方便得多——身份证一递，稍等片刻就能拿到房卡。房间的干净程度、布置标准，也远胜一筹。没有对比就没有伤害。当然对钱包的伤害也挺大的。

食物​

出门在外，有外卖吃倒不是很成问题，倒是喝个热水或是泡个茶包/咖啡包尤为困难，因为你不确信酒店的热水壶是否泡过什么不明物体，是否卫生。

如果可以带个便携式热水杯(小米)，比普通水杯略大，解决“热水自由”不在话下。

衣着​

既然出远门，穿着上肯定不能像在家那样随意。一次性用品（内裤、袜子）非常实用，不必担心换洗问题。其实带上 2~3 套衣物就足够了，前提是你住的酒店配备有洗衣机和烘干机——这又回到了上文说的住宿体验问题。

如果可以记得带 1-2 套一次性的沐浴用品(如毛巾、浴巾、拖鞋)，以免会有住在朋友家里的情况。

出行​

不得不感叹国内交通的便利——高铁的效率远超飞机**，几乎成了我首选。不需要提前两小时抵达机场、不用脱鞋安检，也不怕天气延误。

如果你常坐一等座，会发现很难抢到 1F 的座位，那通常是乘警的工作席（我曾坐过 1D 的位置）。若你不小心选到了这个位置，又略微社恐，可以考虑改签到其他位置。

高铁网络波动较大，我会趁这个空档听听歌、翻翻相册、记录些文字，也算一种旅途中的“放空”。记得带个眼罩或墨镜，睡得更香。

记录​

我不擅长拍照，也没有什么技巧，但我很喜欢苹果相册的一个功能：它会根据拍摄地点自动在地图上打点，并按位置整理照片。无形中帮我记录下那些风景与当下。

不过记得请关闭图片的网络权限，否则 Icloud 会在后台悄悄同步照片，一不留神流量就没了（我就是这样被莫名其妙地扣了近 50 元）。

还有就是在录制视频时如果是 4K 60fps，那手机存储很快就会告急。

开销​

我并未对本次的旅行做一个明细的开支记录，不过可从消费账单记录略知大概。

微信	支付宝

因为辗转了许多城市，所以出行上的消费也占了很大一笔。但出去玩最主要的还是在居住上。不过其中最贵的一笔是 EDC 电音节的门票。

感悟​

如果用一个成语来形容这次旅行，那便是“漫无目的”。

究其原因，还是源于我的性格。我是一个很宅的人，哪怕只是独自去趟小卖部，都会感到不自在，更别提一个人独自在外旅行了。这种不安感像是与生俱来的，总觉得和周围人之间隔着一道无形的墙。时间久了，孤独感便悄然滋生。

我不敢去想象一个人身处陌生城市、身边没有朋友的感觉。或许，如果身边能有一个人陪着一起旅行，一切都会变得不一样。嗯，看来是时候考虑找个对象了。

再加上我有严重的选择困难症，连吃顿饭都能犹豫半天。有段时间甚至靠“随机餐食选择器”才能决定下一顿吃什么。独自出门旅行本就挺无聊的，尤其在没有人带路、自己又不擅长做攻略的情况下，更加显得手足无措。

旅行，并不总是轻松惬意的度假。它更多时候意味着一种尝试，一种挑战。这次旅程虽然留有些许遗憾，还有许多未能尝试的美食、未曾到达的地方。但正因如此，相较于吃喝玩乐本身，体验才显得值得留念。

迟到的毕业证书​

由于之前经历了转专业+休学以及一系列旷课行为导致挂科学分不够，最终不得不在临近毕业时为这些“买单”（出来混总是要还的）。在大四下的时候，有几场考试的时间被安排在发毕业证之前，这意味着我会比他人晚拿到毕业证(大约 2 周)。

不过因祸得福的是，由于延毕所导致我的学生认证资格一直延续到现在，预估明年 6 月毕业季时，我的学生认证才会真正到期。

要我说读大学对我有什么用的话，我能回答的或许只有学生认证所带来的各种优惠，而非传统大学教育为我提供了什么有价值的东西。

上大学对我说算是一种束缚，甚至让我一度怀疑我所读的不是一所的“大学”，反而是所“监狱”。

上大学也是我愧对于父母的一件事情，我也一直不愿意与他们诉说我在大学期间做了什么，因为解释给他们晦涩难懂，何况大学期间发生的变故差点让我难以毕业。

每当他人提起我的学校，我总会有点莫名的哽咽，因为大学很垃圾，难以说出口，我一直不愿说我是本校的学生，且有意为之将有关学校的信息隐秘于世，宁可告诉别人我没读过大学，也不愿让其知道大学名字。

或许当年直接选择辍学而非休学能真正抹除自己内心的阴霾。

初次面基​

在结束了毕业论文答辩，于是决定去广州与网友面基。这是我第一次网友线下面基，再次之前我甚至都没有去过北上广深，甚至这是我自己第一次一个人出省玩🥲。

面基的第一天网友就带我体验了 livehouse，还用无人机拍下广州塔的美景。

后面一起去深圳参加了 VueConf 大会，也是我第一次参加这种大型技术活动。之后还计划一同去🇭🇰搞卡，然而和去年一样，由于特殊原因，今年的我依旧办理不了港澳通行证😔

下半年参加 Feday 有幸见到了一些大佬，技术的氛围感，让我感受到了一种前所未有的激动。明年的我一定要面基更多的网友，去更多的地方，体验更多的生活。

结束了短暂的游玩时光，终于要开始苦逼的牛马生活了，吗？

初入职场​

和绝大多数刚毕业的应届生一样，在家人的建议和考虑下，我最终选择去福州和我姐一起生活和工作，这样既能照应彼此，减轻一些生活压力的同时，还能提高生活幸福指数。

事实也确实如此，在我姐的几年生活经验下，我几乎不用考虑衣行吃住，在福州过得是有滋有味。一向宅男的我在我姐的怂恿下尝试了很多不一样生活的方式，并不是只有宅在家里才是活着（虽然在家里活着确实挺舒服的😂）。

在五一的节假日期间，我准备完简历与项目后开始找工作去，这一段的求职与就业的感悟故事我也记录了下来。

记 · 在 AI 公司入职一个月的体验与感悟

然而在工作了三个月后，我逐渐发现公司内部异常混乱。在这段时间里，我被卷入高管之间的内斗，沦为他们博弈的工具人。试用期结束时，不但被卡转正，还遭遇了疯狂的职场PUA和无止境的压榨。

就在我萌生离职念头时，没想到我的前领导竟然比我更快一步离职。而我却做出了一个让我至今懊悔的决定——接手前领导的活，还选择吃下老板画的大饼。在这种超负荷的状态最终只让我坚持了一个月。9月30日这一天，我终于下定决心递交了辞呈，给自己放了一个真正的长假。😇

期间所发生的故事尤为精彩，我也将其整理了下来，也算是给我的职业生涯增添了浓墨重彩的一笔。

至于说现在这个 AI 初创公司发展的如何，或许是在濒临倒闭的边缘，不过我现在只清晰地记得离职那天一刻无比愉悦的心情😆。

游戏艺术​

离职回到老家的我第一时间玩起了《黑神话·悟空》，之前玩的是《黑公司·牛马》。我特意为此购入了XBox手柄，只为离职之后的娱乐尽兴一把。

今年年初在朋友的怂恿下玩《荒野大镖客 2》。也是从这部作品刷新了我对游戏的认知，让我开始对这类游戏产生了浓厚兴趣，让我意识到游戏不仅仅是一个娱乐方式，更像是部电影、艺术，每一帧画面、每一段配乐、每一个剧情都蕴含着制作者的匠心。不仅是对自己兴趣的一次探索，也是一种对高品质游戏制作的致敬。

远程工作​

就当我即将结束我的长假之时，一则私信引起了我的注意。

对方看到我的技术栈与他的项目十分贴合，阅读了我职场故事会（原来写小作文真有用啊），便向我抛出橄榄枝，但当时的我还没那么想要再次进入工作状态，况且这家公司又是 AI 初创公司（我对初创公司已经有 PTSD 了，生怕再经历类似的职场故事🥲），所以当时的我对这份机会此挺无所谓的。

后面进一步的了解，发现是老板自己搞 B2B 的项目，不愿招外包，于是就在 X 上招聘，并找到了我。于是安排了场 2 小时视频通话，聊了聊我过往的项目经历，就这样拿到了该 Remote 的 Offer 😄，同时也多了一位美国朋友。

即便没有这个 Remote 机会，我也会选择尝试寻求其他海外的远程工作机会，因为我已经对坐班工作产生了厌倦感，我想要的更多是自由，而非束缚。

虽说是初创公司，但各种合同手续也都齐全，还是先发工资再干活（用老板的话讲就是：他先发薪资是我欠老板的，我先干活再拿钱是我欠老板的），时间上自由不少(就是要倒时差)， AI 工具服务必须齐全。本来还答应圣诞给我换台 Macbook，不过我还没到换设备的程度（其实是我觉得换设备迁移数据太麻烦了）。

业余时间的视频会议还让我看了真🔫，大🚬，这很🇺🇸特色。不过对我最不适应的还是来自于沟通而非技术。也让我深刻意识到了英语在远程工作，乃至未来职业发展的重要性。

去年这时候我对我未来的职业规划有所思考，其中就提到了远程工作。如今我确实达到了当初对职场的期望。

或许是因为过往的职场经历在简历上不够看，大厂经历或许能给职业生态添金，加上学历的自卑，总让我对大厂一直怀有向往。但当我与一些大厂员工的谈话之后，他们反倒羡慕我的远程工作生活，至少不用 996，不用坐班。或许这就是人们总是向往他人的生活，却不知对方的苦恼。

🐈

突如其来的变故致使我不得不马上搬家，正当决定新住所的时候，脑海里浮现直接回到老家生活并开始 Remote 工作的决定，并且还能迎接了我的新伙伴😽

我一毕业就想养猫，但我姐的鼻子对味道特别敏感，与她同住就更不可能了（这才是我回老家的最大原因），因为搬家的变故，养猫成为了现实。

养猫让我身心舒畅，但也让我分心乏力。关于养猫的记录，我想过段时间经历了更多再做更细致的分享，是一篇劝退指南😿。

给自己的话​

相比以往在大学期间自我摸索技术，今年尝试了很多之前不曾接触的事情。网友面基，参加技术大会，游玩方特，远程工作，养猫等等，相比之前大学期间只会宅在家里专研技术，却不懂的体验生活的我，或许是因为喜欢折腾的性格，也或许是因为大学期间的压抑，让我在现在更加渴望体验生活。

这一年，从独自摸索到与团队协作，从封闭的校园到远程工作，也让我逐渐认识到，技术只是工具，技术的提升可能是人生中最不起眼的东西，更有意义的是这个过程的体验、成长、感悟。

感谢自己愿意尝试未知，希望这份勇于尝试的心态让我始终保持热爱与激情。

往年回顾​

• 2023 · 谈谈职业规划
• 2023 · 叙一名转专业+休学的大学生经历
• 2022 · 逆向到Web开发
• 2021 · 休学一年
• 2020 · 编程之旅-起点

这还没完，当你需要数据验证、错误处理、中间件等等功能，又得花费不小的功夫，所以 Next.js 的 API Route 更多是为你的全栈项目编写一些简易的 API 供外部服务，这也可能是为什么 Next.js 宁可设计 Server Action 也不愿为 API Route 提供传统后端的能力。

但不乏有人会想直接使用 Next.js 来编写这些复杂服务，恰好 Hono.js 便提供相关能力。

这篇文章就带你在 Next.js 项目中要如何接入 Hono，以及开发可能遇到的一些坑点并如何优化。

Next.js 中使用 Hono​

可以按照 官方的 cli 搭建或者照 next.js 模版 https://github.com/vercel/hono-nextjs 搭建，核心代码 app/api/[[...route]]/route.ts 的写法如下所示。

import { Hono } from 'hono'
import { handle } from 'hono/vercel'

const app = new Hono().basePath('/api')

app.get('/hello', (c) => {
  return c.json({
    message: 'Hello Next.js!',
  })
})

export const GET = handle(app)
export const POST = handle(app)
export const PUT = handle(app)
export const DELETE = handle(app)

从 hono/vercel 导入的 handle 函数会将 app 实例下的所有请求方法导出，例如 GET、POST、PUT、DELETE 等。

一开始的 User CRUD 例子，则可以将其归属到一个文件内下，这里我不建议将后端业务代码放在 app/api 下，因为 Next.js 会自动扫描 app 下的文件夹，这可能会导致不必要的热更新，并且也不易于服务相关代码的拆分。而是在根目录下创建名为 server 的目录，并将有关后端服务的工具库(如 db、redis、zod)放置该目录下以便调用。

至此 next.js 的 api 接口都将由 hono.js 来接管，接下来只需要按照 Hono 的开发形态便可。

数据效验​

zod 可以说是 TS 生态下最优的数据验证器，hono 的 @hono/zod-validator 很好用，用起来也十分简单。

import { z } from 'zod'
import { zValidator } from '@hono/zod-validator'
import { Hono } from 'hono'

const paramSchema = z.object({
  id: z.string().cuid(),
})

const jsonSchema = z.object({
  status: z.boolean(),
})

const app = new Hono().put(
  '/users/:id',
  zValidator('param', paramSchema),
  zValidator('json', jsonSchema),
  (c) => {
    const { id } = c.req.valid('param')
    const { status } = c.req.valid('json')

    // 逻辑代码...

    return c.json({})
  },
)

export default app

支持多种验证目标(param,query,json,header 等)，以及 TS 类型完备，这都不用多说。

但此时触发数据验证失败，响应的结果令人不是很满意。下图为访问 /api/todo/xxx 的响应结果（其中 xxx 不为 cuid 格式，因此抛出数据验证异常)

所返回的响应体是完整的 zodError 内容，并且状态码为 400

因为 zod-validator 默认以 json 格式返回整个 result，代码详见 zod-validator/src/index.ts#L68-L70

这就是坑点之一，返回给客户端的错误信息肯定不会是以这种格式。这里我将其更改为全局错误捕获，做法如下

1. 复制 zod-validator 文件并粘贴至 server/api/validator.ts，并将 return 语句更改为 throw 语句。

   if (!result.success) {
-    return c.json(result, 400)
   }

   if (!result.success) {
+    throw result.error
   }

2. 在 server/api/error.ts 中，编写 handleError 函数用于统一处理异常。（后文前端请求也需要统一处理异常）

import { z } from 'zod'
import type { Context } from 'hono'
import { HTTPException } from 'hono/http-exception'

export function handleError(err: Error, c: Context): Response {
  if (err instanceof z.ZodError) {
    const firstError = err.errors[0]

    return c.json(
      { code: 422, message: `\`${firstError.path}\`: ${firstError.message}` },
      422,
    )
  }

  // handle other error, e.g. ApiError

  return c.json(
    {
      code: 500,
      message: '出了点问题, 请稍后再试。',
    },
    { status: 500 },
  )
}

3. 在 server/api/index.ts ，也就是 hono app 对象中绑定错误捕获。

const app = new Hono().basePath('/api')

app.onError(handleError)

4. 更改 zValidator 导入路径。

- import { zValidator } from '@hono/zod-validator'

+ import { zValidator } from '@/server/api/validator'

这样就将错误统一处理，响应体也自定义，且后续自定义业务错误也同样如此。

RPC​

Hono 有个特性我很喜欢也很好用，可以像 TRPC 那样，导出一个 client 供前端直接调用，省去编写前端 api 调用代码以及对应的类型。

这里我不想在过多叙述 RPC(可见我之前所写有关 TRPC 的使用)，直接来说说有哪些注意点。

链式调用​

还是以 User CRUD 的代码为例，不难发现 .get .post .put 都是以链式调用的写法来写的，一旦拆分后，此时接口还是能够调用，但这将会丢失此时路由对应的类型，导致 client 无法使用获取正常类型，使用链式调用的 app 实例化对象则正常。

替换原生 Fetch 库​

hono 自带的 fetch 或者说原生的 fetch 非常难用，为了针对业务错误统一处理，因此需要选用请求库来替换，这里我的选择是 ky，因为他的写法相对原生 fetch 更友好一些，并且不会破坏 hono 原有类型推导。

在 lib/api-client.ts 编写以下代码

import { AppType } from '@/server/api'
import { hc } from 'hono/client'
import ky from 'ky'

const baseUrl =
  process.env.NODE_ENV === 'development'
    ? 'http://localhost:3000'
    : process.env.NEXT_PUBLIC_APP_URL!

export const fetch = ky.extend({
  hooks: {
    afterResponse: [
      async (_, __, response: Response) => {
        if (response.ok) {
          return response
        } else {
          throw await response.json()
        }
      },
    ],
  },
})

export const client = hc<AppType>(baseUrl, {
  fetch: fetch,
})

这里我是根据请求状态码来判断本次请求是否为异常，因此使用 response.ok，而响应体正好有 message 字段可直接用作 Error message 提示，这样就完成了前端请求异常处理。

至于说请求前自动添加协议头、请求后的数据转换，这就属于老生常谈的东西了，这里就不多赘述，根据实际需求编写即可。

请求体与响应体的类型推导​

配合 react-query 可以更好的获取类型安全。此写法与 tRPC 十分相似，相应代码 → Inferring Types

// hooks/users/use-user-create.ts

import { client } from '@/lib/api-client'
import { InferRequestType, InferResponseType } from 'hono/client'
import { useMutation } from '@tanstack/react-query'
import { toast } from 'sonner'
const $post = client.api.users.$post

type BodyType = InferRequestType<typeof $post>['json']

type ResponseType = InferResponseType<typeof $post>['data']

export const useUserCreate = () => {
  return useMutation<ResponseType, Error, BodyType>({
    mutationKey: ['create-user'],
    mutationFn: async (json) => {
      const { data } = await (await $post({ json })).json()

      return data
    },
    onSuccess: (data) => {
      toast.success('User created successfully')
    },
    onError: (error) => {
      toast.error(error.message)
    },
  })
}

在 app/users/page.tsx 中的使用

'use client'

import { useUserCreate } from '@/features/users/use-user-create'

export default function UsersPage() {
  const { mutate, isPending } = useUserCreate()

  const handleSubmit = (e: React.FormEvent<HTMLFormElement>) => {
    e.preventDefault()
    const formData = new FormData(e.currentTarget)
    const name = formData.get('name') as string
    const email = formData.get('email') as string
    mutate({ name, email })
  }

  return (
    <form onSubmit={handleSubmit}>
      <div>
        <label htmlFor='name'>Name:</label>
        <input type='text' id='name' name='name' />
      </div>
      <div>
        <label htmlFor='email'>Email:</label>
        <input type='email' id='email' name='email' />
      </div>
      <button type='submit' disabled={isPending}>
        Create User
      </button>
    </form>
  )
}

OpenAPI 文档​

这部分我已经弃坑了，没找到一个很好的方式为 Hono 写 OpenAPI 文档。不过对于 TS 全栈开发者，似乎也没必要编写 API 文档（接口自给自足），更何况还有 RPC 这样的黑科技，不担心接口的请求参数与响应接口。

如果你真要写，那我说说几个我遇到的坑，也是我弃坑的原因。

首先就是写法上，你需要将所有的 Hono 替换成 OpenAPIHono (来自 @hono/zod-openapi， 其中 zod 实例 z 也是)。以下是官方的示例代码，我将其整合到一个文件内

import { createRoute, OpenAPIHono, z } from '@hono/zod-openapi'
import { swaggerUI } from '@hono/swagger-ui'

const app = new OpenAPIHono()

const ParamsSchema = z.object({
  id: z
    .string()
    .min(3)
    .openapi({
      param: {
        name: 'id',
        in: 'path',
      },
      example: '123',
    }),
})

const UserSchema = z
  .object({
    id: z.string().openapi({ example: '123' }),
    name: z.string().openapi({ example: 'John Doe' }),
  })
  .openapi('User')

const route = createRoute({
  method: 'get',
  path: '/api/users/{id}',
  request: {
    params: ParamsSchema,
  },
  responses: {
    200: {
      content: {
        'application/json': {
          schema: UserSchema,
        },
      },
      description: 'Retrieve the user',
    },
  },
})

app.openapi(route, async (c) => {
  const { id } = c.req.valid('param')

  // 逻辑代码...
  const user = {
    id,
    name: 'Ultra-man',
  }

  return c.json(user)
})

从上述代码的可读性来看，第一眼你很难看到清晰的看出这个接口到底是什么请求方法、请求路径，并且在写法上需要使用 .openapi 方法，传入一个由 createRoute 所创建的 router 对象。并且写法上不是在原有基础上扩展，已有的代码想要通过代码优先的方式来编写 OpenAPI 文档将要花费不小的工程，这也是我为何不推荐的原因。

定义完接口(路由)之后，只需要通过 app.doc 方法与 swaggerUI 函数，访问 /api/doc 查看 OpenAPI 的 JSON 数据，以及访问 /api/ui 查看 Swagger 界面。

import { swaggerUI } from '@hono/swagger-ui'

app.doc('/api/doc', {
  openapi: '3.0.0',
  info: {
    version: '1.0.0',
    title: 'Demo API',
  },
})

app.get('/api/ui', swaggerUI({ url: '/api/doc' }))

从目前来看，OpenAPI 文档的生成仍面临挑战。我们期待 Hono 未来能推出一个功能，可以根据 app 下的路由自动生成接口文档（相关Issue已存在）。

仓库地址​

附上本文中示例 demo 仓库链接（这个项目就不搞线上访问了）

https://github.com/kuizuo/nextjs-with-hono

后记​

其实我还想写写 Auth、DB 这些服务集成的(这些都在我实际工作中实践并应用了)，或许是太久未写 Blog 导致手生了不少，这篇文章也是断断续续写了好几天。后续我将会出一版完整的我个人的 Nextjs 与 Hono 的最佳实践模版。

也说说我为什么会选用 Hono.js 作为后端服务, 其实就是 Next.js 的 API Route 实在是太难用了，加之轻量化，你完全可以将整个 Nextjs + Hono 服务部署在 Vercel 上，并且还能用上 Edge Functions 的特性。(就是有点小贵)

但不过从我的 Nest.js 开发经验来看（也可能是习惯了 Spring Boot 那套三层架构开发形态），总觉得 Hono 差了点意思，说不出来的体验，可能这就是所谓的全栈框架的开发感受吧。

已经在一家 AI 公司入职了一个月，对坐班有些厌恶的我，没想到有一天也会开始通勤打卡。而经历了这一个月的工作，我对坐班的态度有所转变，开始理解这种工作方式对我的意义。是时候分享入职这期间的工作内容与感受。

背景​

直入正题，先说职位背景。该职位的技术要求大致如下，仅做参考。

## 任职要求 
1. 本科及以上学历，计算机科学、软件工程等相关专业, 硕士优先； 
2. 扎实的 HTML、CSS、JavaScript 基础(vanilla) 功底 ； 
3. 熟练使用 React、React Native 和 Next.js 进行前端开发 
4. 了解前端性能优化技术，如代码压缩、懒加载等 
5. 熟悉前端工程化工具 
6. 具备良好的问题解决能力和团队协作精神 
7. 熟练阅读英文技术文档 
8. 有优异前端项目开发经验者优先 

## 加分项： 
- 贡献开源社区 
- 有 AI 相关项目经验。 
- 有前端性能优化和 SEO 优化经验。 
- 有良好的产品思维和设计(UI/UX)意识。 
- 有同理心思维。
- 具有一定的审美感。

很贴合国外主流的技术栈（至于为何，看后文便知），比较巧的是，我的 Web 全栈学习路线就是偏国外的技术栈。因此在技术栈上，这家公司是我喜欢的，恰巧又是 AI 开发，能让我尝试到一些前沿技术，也正好是想我折腾的。

求职经历​

我是 Boss 直聘上找的（这里没给 boss 直聘打广告，我甚至还是第一次使用 boss 直聘），我有想过找人内推，但由于家庭因素被限定在福州这座城市，而内推的所在的城市往往都是那些一线城市，加上我的八股文和算法很不过关（我也很不情愿刷），到时候面试那关估计也不乐观。

因此就在 Boss 上碰碰运气，也顺带体验一下新人都是怎么找工作的。

从五一的时候开始准备简历和项目，在5号开始投简历，投递简历一关我是直接怼着工作经验1-3年的来投，而不是投应届或实习岗。因为我确实有一些工作经验，只不过不是正常的坐班打卡的形式，这在之前的博客中有说到。

在这期间共投了20多家，基本都是已读不回，就更别说投递简历了。后来我才了解到，原来 HR 回复消息是要花钱的，发布一个岗位也是。

唯一回复的还是我现在入职的这家，而且我还投了两份过去，一份是给 HR 的（没回），一份是给技术 leader 的（leader 回了）。

面试被鸽​

可能是由于当时这个岗位急招的原因，在 boss 直聘上也没多说什么，leader 就约明早 11 点来公司现场初步面试聊天一下。这期间还发生了一个小变故，我到公司了，可联系不上面试官，打了微信电话也无果。待了10来分钟后我就走了，等了约一个小时都没信息，那我大概率是被鸽了，还不提前和我通知一声，然后在boss上留下了这句评价🥲。

初入职场，初次面试就这种情况，说真的我当时都有点心灰意冷了，我猜想是不是因为有其他合适的人选，于是就不招我了，就连信息也不给我打一个招呼，相当于把我拉黑似得。随后我就到附近的麦当劳花了 10 元的套餐安慰了一下自己，麦！

开始面试​

直到到下午一点多的时候，面试官回复我说当时他们在开会，期间不让携带电子设备。早上就当一面过了，问我下午有没有时间，直接二面技术面(code test)过了就直接拿offer。

这时我才知道，原来早上也仅仅只是我的猜想，但我还是有点不想去了，心情有点不太愉悦，但想了想也懒得计较了，过去就当聊天罢了。到了下午面试问的就偏前端基础、八股文那些问题，其实我回答的巨烂，确实也没好好刷题，也不喜欢刷题，就面试了。自己写代码是由业务环境下驱动的，并从中寻求最佳实践。但好在我的技术面是比较广的，很多前沿的前端相关的工具库或多或少都使用过，也能侃侃而谈，加上个人 blog 和 github 这两个大加分项。就进入到了一个代码考核测试，不限框架，不限规则，使用公司的电脑打开 codesandbox 写一个todo list，前提是不使用任何 AI 工具。

这不正好到了我的强项，之前学某个框架的时候，不知道写什么demo，就写 todo list 来练手😂。恰好这次我就使用 next.js app router + Tailwindcss 的模版并且使用 form 标签的 action 和 use server 来实现新增功能。 能体现出我有在使用 next.js，而且用上了一些新特性，就拿到 offer 了。

听完之后是不是莫名的感觉这个 offer 拿的好像有点莫名其妙的感觉😂，不管怎么样结果是好的就行了。

不过拿到 offer 后，我并没有选择马上入职，经历了一次被鸽的经历，对该公司的印象带有一些怀疑。其次就是这是一家初创 AI 公司，规模不大，从应届生找工作的角度，第一份正式的工作的起点很关键，如果能直接进大厂，后续跳槽到其他公司大概率也不成问题。

但在当地我投递了 20 多家已读不回的情况下，加上这份已有的 offer 不等人（急招），加上我家里人给我推荐的工作内容我并不是很满意，于是思考了两天，最终还是选择入职了这家公司。

薪资​

比较令我差异的是我与企业签订的直接劳动合同，可能是因为我直接投递 1-3 年的工作经验，但我此时的身份还是应届生，按理来说我应该是签订实习合同后，转正再签劳动合同，难道说我已经提前转正了？。不过也好，这样和学校的三方协议都可以不用签了，直接给劳动合同便可。

试用期 3 个月，薪资打 8 折。薪资在我当地还算 ok，但对于我而言并不理想。可能是会的比较多(全栈？全干！)，加上曾经赚过比这还高上许多的薪资，从内心的角度多少是有些不平衡。不过目前还是试用期，薪资这方面后续也能再谈。

接下来尤为重要的上班体验才是让我觉得没后悔入职这家公司。

上班体验​

介绍一下公司部门的办公工具

办公管理：企业微信

团队协作：Slack

任务看板：Trello

代码仓库：Github

代码托管：Vercel

视频会议：Zoom

你会发现除了企业微信，其他的应用都是国外的。怎么看都不是一家国内的企业吧，这是因为我部门的 Leader 是海外留学的，这也就不难理解工具是国外应用，技术栈选型是 React 生态了。

入职的第一周部门开了个小会，就是简单介绍了一下部门的任务职责，每个成员自我介绍。重点是提供一个优质的学习环境，像是技术书籍，电子设备，UI 模版或是技术会议的门票等费用，只要对部门有利，能提升自己，都可以找他报销。

我已经找 Leader 报销了个 magic ui pro，大约 420 块，直接找财务刷卡，付款的感觉是真爽，我是真爱了🥰。

几天后，公司来了一个阿里做 B 端低代码开发的同事，也是负责前端开发，这不，我可以间接和这个老哥那学习大厂相关经验，我还正愁着没大厂相关的经验😄。

我询问他来这家公司的原因，他说被裁了，在家接外包一年了，不稳定就准备找工作，恰好这家公司急招，于是就来了。

团建​

在我入职的第一周周末 Leader 为整个部门安排团建，由于这个部门成立不到 2 周，来的都是新成员，让我们自己组个局，去外面吃个饭。

也是在团建的时候了解到同事的履历一个个都不简单，有 985 的，有海外留学的，有在阿里、网易待过的，还有我这不堪回首的经历 🤡。

后面原定在 61 安排整个公司的团建，但由于天气和周末时间去的人少的因素而取消了，这我就不多说了。

端午之后的第一个工作日的中午，补过端午节部门聚餐的，这我也不多说了。就是怎么感觉这频率有点不太对，然后实际项目产出也还停留在 Spring 1 的阶段，让我有些不自在。

福利​

部门每个月都会定一个最佳员工奖，我很荣幸获得部门本月的最佳员工，也感谢部门成员的认可，奖励是 300 元奖金或一日自由假。

甚至还有一张奖状，就是这奖状怎么有点像给小学生似的。（事后我才了解到这奖状还是用打印机打印的😂）

目前我已经能感受到最大的福利就是那个 magicui 动效库的模版，当然了，这个是要给公司的官网用上的，我也是蹭公司的福，给自己的站点用上了这个动效库。

此外像节日福利，如这次端午节，就是聚餐和发粽子，这也就没什么好说的。

通勤​

公司距离我租房的地方只有 2 公里，每日的通勤总时间大约 40 分钟，早上大约 8 点起床，我通常坐公交车到公司附近的早餐店吃个早饭，吃完差不多 8 点 40分~50 分。中午外卖就不说了。下午下班从公交车和走路做个选择，吃完饭回到家。

黑客松​

黑客松(hackathon)，也称编程马拉松比赛。我是第一次听说过这个词，Leader 给定两个选题一个是打造某市地铁智能出行，另一个是给某商场的提供贴心的购物体验，发挥自己近一个月所学的知识，去创造一个供用户使用的 AI 程序，月底交付，奖金 3000 元/小组，抽签分组。我们当时部门有个人提了一嘴，要不我们两小组自己商量一下，把奖金平分得了😂。

不过对于这个行为，我个人认为目的是为了激励员工之间协同合作，但同时也免不了技术上的内耗，毕竟这个比赛不是我们的主要工作内容。

工作内容​

我想肯定有很多人对 AI 开发的刻板印象是要会大模型开发，会懂得微调，会懂得人工智能算法。这个想法也没错，但从开发 AI 应用的角度，其实蛮需要前端的，尤其是会全栈框架的前端。

这里我不得不惊叹 next.js 的生态，很多 AI 相关的例子可以直接从 Vercel 的 AI Template 下学习，预览是否有你需要的功能，Clone 到本地，然后运行项目，对某些部分进行更改。搭建 AI 应用也是异常的快。

仿 AI SDK 网站效果​

Leader 下发的一个任务，入职的前两周主要让我熟悉一些怎么使用 next.js 配合 vercel 的 ai sdk 来开发 AI 应用，如怎么调用 openai 的模型，实现一个 ai chatbot。给定了一个任务就是仿造 AI SDK，由于该项目没有开源，自然就只能另辟蹊径。

首先就是仿造页面了，这个作为前端开发，实现起来也算容易，更何况这个这个页面的样式使用 Tailwindcss 编写，直接通过审查元素仿造就行了。

其次在功能实现上，ai sdk 文档都提供了非常完善的解决方案，照着文档将代码稍微改写一下便可，具体的细节就不演示了。

官网首页​

两周后开始正式项目开发了，首当其冲的就是官网页。

这里当时 Leader 问我有没有用过 Gatsbyjs，要用这个框架搭建一个官网。我表明我没用过，但我提了一嘴如果要搭建偏内容向的网站，可以考虑 Astro，我愿意折腾一番（我也一直想学 Astro 的）。不过最终在开发时间和成本的商讨下还是选择使用 next.js 来搭建，leader 还顺带给我推荐了一个动效库 magicui，叫我看看里面的案例，看看能不能给官网加点动效。 之后就有了上文提到报销 magicui 的事。

Rag bot​

篇幅实在有限，有关 RAG 的不做过多解释，它可以让你的 AI 应用更具有权威性，让数据的来源可靠，而非胡乱生成数据。

RAG 的基本流程就是：

1. 用户输入提问
2. 检索：根据用户提问对 向量数据库 进行相似性检测，查找与回答用户问题最相关的内容
3. 增强：根据检索的结果，生成 prompt。 一般都会涉及 “仅依赖下述信息源来回答问题” 这种限制 llm 参考信息源的语句，来减少幻想，让回答更加聚焦
4. 生成：将增强后的 prompt 传递给 llm，返回数据给用户

在这个应用开发中，借鉴了 ragbot-starter 这个开源项目，同时向量数据库选用 datastax 公司的Astra DB。

恰好在开发这个应用的期间，我也正好在学习 Langchain.js，所以在数据处理这部分有点得心应手，目前应用还只停留在处理本地文件或用户上传的文件，只需要配置各种 File Loader 便可。

使用 RN 实现 chatbot​

先看 Gif 效果。

第一次用 Screen Studio，显示的不是很好，还请见谅，主要就是实现一个流式文本效果。

这里简单说下怎么实现的，就用 react-native-reusables 的模版(React native 的 Shadcn/ui) + react-native-gen-ui 实现的，不过后者的功能比较单一，后续估计要改代码了。代码就不贴了，我怕涉嫌代码泄露（其实已经泄露差不多了）。

收获​

要我说最大的收获不是遇到一个氛围不错的公司，遇到一个好 leader，也不是接触 AI 开发从中学到了什么，更不是增进了我的技术栈。而是让我养成良好的习惯，开始正常一日三餐，开始作息规律，开始将工作与生活分离，身体状态也渐渐好了起来。

下图为 5 月的生物作息，基本都保持 0 点前入睡。（不过在我写这篇文章的时候已经两点了🥱）

过去几年内我的作息与饮食都非常糟糕，能明显的感觉到状态有所下滑，编写代码的效率和能力也明显不如以前，有些力不从心。今年都快过去一半了，而我仅仅完成了2篇博文的写作，文章的输出效率明显不行😮‍💨。

在半年前我对自己当时的现状做了个分析，幻想着坐班或许能改变我当下的现状。如今经历了这一个月的坐班生活，可能是因为坐班而改变，也可能是公司的氛围，不管是那种，让我跳出我原有舒适区，重新拾起对新颖事物的兴趣，重新点燃学习某个技术的热情，重新找回了自我。

结尾​

在我还没找工作之前，从我几个同届毕业的同学和网友的反馈得知今年的就业环境异常险峻。不仅如此，我还在网络上看到了大量工作者对自身工作的抱怨与不满，这些现象让我在工作前让我对未来的就业前景感到了一些不安。

当我亲身入局感受一番，也不禁开始低声叹气。开始思考是什么原因导致了如今大环境不好的现象，人为的制造就业焦虑，还是当下现实本就如此。当我跳出思考，回到现实难道环境好就一定挣钱多，环境差就一定挣钱少吗？社会似乎并不是这么简单的等式。

我逐渐意识到，无论大环境如何，每个人的努力和选择仍是至关重要。在面对不确定性和挑战时，保持学习和进步的态度，以及寻找自己的核心竞争力，才是应对困境的关键。

真正的职业安全感并不完全来自于外部环境，而是来自于我们自身不断提升的能力和适应变化的灵活性。

代码仓库： https://github.com/kuizuo/youni

为什么是 RN 而不是 Flutter？​

很简单，就是技术栈问题。从开发角度而言，尤其还是对于前端开发人员，会 JS 且搞过 React ，那 RN 上手就十分友好，最起码有关 React 社区的逻辑库或状态库是可以使用的。

虽说 Flutter 的性能是会比 RN 好上不少，但抛开需求不谈，与其比性能不如比开发速度。很显然开发 RN 的效率比 开发 Flutter 高上不少。况且真在意性能的话，那多半就不会考虑跨平台技术了，而是直接考虑原生开发了。

再从需求考量，我所编写的应用更偏向于内容展示的 app，而不是编写一个手机电池监控或者内存监控的app，如果是后者，那这时选择任何跨平台开发都没有意义，像这些系统级别的API在跨平台开发基本不太可能实现的。

对于这两个跨平台技术的选择，应该考虑自身需求、开发成本、技术选型，没有最好的只有最适合的。如果有的选择，谁不会选择原生开发是吧。

但凭我自己接触 RN 以来，国内的 RN 资源甚少，反倒是 Flutter 资源很多，并且从这些相关资料来看，确实 Flutter 优于 RN，但还是那句话，这里就不再过多赘述了。

是否有必要学 react-native？​

先说一个结论：RN ≠ 原生，别指望会个 react 就能写出靠谱的原生应用。

就从我的开发经历来说，坑是真的多，但好在RN拥有庞大的线上社区，可以找到的几乎所有问题的答案。但国内的社区好像并不是很好，很多问题我都是在国外论坛中解决的。

如果你学习它是为了扩展其他平台的开发能力，那么还是可以学习一番的，会有另一番的收获。但如果学 RN 只是为了避免不用学 android 和 iOS 等原生技术就能写 app，那便不建议学习。抱着这心态的话前期开发可能不明显，但到了后面会踩很多坑，而且两眼一黑，因为你不懂 native 开发。

我的个人评价是 RN 只能作为 H5 手机页面运行在原生移动设备的一种展示形态。虽然本质不是，但其所展示的效果如同。RN 不仅仅只是 Web，但也止步于 Web。

顺带吐槽一番，React-Native 项目发布4年多了，还没有 1.0 版本么(¬_¬)

如果你想再继续了解 RN，那么就请往下看。

Expo​

Expo 是基于 React Native 并整合大量常用的 native module(Expo SDK)，像原生的功能如相册，相机，蓝牙等功能，在 expo 都是直接集成的，相当于封装原生的api，暴露给js调用。因此你不用去了解原生开发的许多知识和坑点，上手即用便可。本地配置好应用所需的环境，就直接直接运行 RN 项目，开发十分方便。

此外 Expo 还提供了 Expo Go App，只需要在你的移动端设备中安装它，启动开发服务器并生成 QR 码。在浏览器打开 snack.expo.dev ，点击 MyDevice，扫码并在 Expo app 中查看。

会自动将该程序实时运行在你的移动端设备，意味着你更改代码也将会同步到Expo go 中。极大程度上提升 RN 的开发体验，尤其是在真机测试阶段。

Expo 官方还贴心的提供了云服务 Expo Application Services (EAS)，意为这你可以你可以将你的 RN 项目在托管在云服务上，来执行构建与发布等流程。

总之如今开发 RN 请毫不犹豫的使用上 Expo。

开发中遇到的一些坑点​

实际开发中所遇到的坑点远不止下述所说，这里只列举几个相对有代表，坑比较深的点。甚至有很多坑都不是前端方面的知识了。

在 pnpm 下无法启动 Android​

错误提示：Error: Unable to resolve module ./nxode_modules/expo/AppEntry

解决方案：在项目根目录创建 .npmrc ，内容如下

shamefully-hoist=true
node-linker=hoisted

删除 node_modules 与 .expo 文件夹，重新安装依赖即可。

相关链接：https://github.com/expo/expo/issues/9591#issuecomment-1485871356

样式问题​

在样式方面与传统的 Web 开发存在一定的区别。在 RN 中有两个主要组件，View 与 Text，可以理解为 Web 的 div 与 span。基本所有的 View 都是 flex 布局，想要让 View 组件占满通常不会使用 width: ’100%’ 或 height: ‘100%’，而是使用 flex: 1，例如一般都会带上这么一个样式。

<View style={{ felx: 1 }}>

如果样式问题就只是这样就好了，同一套样式在不同平台上所展示的效果都可能不大一样，尤其使用原生 Web 的样式，哪怕你用 style 编写，在 Web 网页也能成功显示效果，但是在 IOS 与 Android 中绝大多数情况下是不显示的。这会在后面介绍 Tailwindcss 相关库的时候会额外在提到一点。

文本必须要用 Text 包裹​

如果不怎么做的话，会报错，如果只是这样倒还没什么。重点是错误提示并没有堆栈信息！就如下图所示

这点对于开发体验而言并不友好。

模拟器无法请求本地 api​

由于一开始是在 Web 端进行调试开发的，所以没留意到这个问题，直到切换到安卓模拟器之后发现模拟器无法请求本地后端服务，在IOS 端暂无这问题。因此需要做如下配置：

1、首先将模拟器内网切换到本地。

假设后端 api 地址为 [http://localhost:6001](http://localhost:6001)，正常情况下，开发环境下的调试主机可以通过如下方式获取

import Constants from 'expo-constants'

const debuggerHost = Constants.expoConfig?.hostUri
// 192.168.123.233:8081

接着所要做的就是将 192.168.123.233:8081 替换成我们的目标端口 192.168.123.233:6001

这里以 axios 为例， 先为环境变量添加 EXPO_PUBLIC_API_URL=http://localhost:6001，具体替换的代码如下所示

export const client = axios.create({
  baseURL: getApiUrl(),
  timeout: 5000,
})

export function getApiUrl() {
  const apiUrl = process.env.EXPO_PUBLIC_API_URL
  return replaceLocalhost(apiUrl)
}

export function getLocalhost() {
  if (localhost !== undefined) return localhost

  const debuggerHost = Constants.expoConfig?.hostUri
  // 192.168.123.233:8081
  localhost = debuggerHost?.split(':')[0] ?? 'localhost'
  return localhost
}

export function replaceLocalhost(address: string) {
  const PROTOCOL = 'http:'
  const localhostRegex = new RegExp(`${PROTOCOL}\/\/localhost:`, 'g')
  return address.replace(localhostRegex, () => `${PROTOCOL}//${getLocalhost()}:`)
}

2、端口转发

此外还需要执行以下命令转发端口。

adb reverse tcp:6001 tcp:6001

此时安卓模拟器便可正常请求本地后端服务的资源，IOS 端并未有该问题。

组件库的选择​

如今在 UI 的选择上，我是毫不犹豫选择 Tailwindcss，在 RN 使用 Tailwindcss 有两个库可以作为选择 nativewind 和 twrnc。

nativewind​

nativewind 采用 Web 的 className 属性，其用法如同 Web 开发使用 Tailwindcss 的写法，这里便不过多展示了。

twrnc​

twrnc 的写法则有些不同，需要通过 tw 包装，然后填写到 style 中，就如下图所示

import { View, Text } from 'react-native'
import tw from 'twrnc'

const MyComponent = () => (
  <View style={tw`p-4 android:pt-2 bg-white dark:bg-black`}>
    <Text style={tw`text-md text-black dark:text-white`}>Hello World</Text>
  </View>
)

事实上有很多 Web 端支持的类，在移动端并不能生效，通常来说只适合用 Tailwindcss 来编写基本的宽高，内外边距等样式。

这两个库的区别​

从 Web 开发使用的角度，nativewind 会更好用一些， npm 实际使用量也确实比 twrnc 来的多，但要在一些情况下，比如给第三方组件更改 props 的样式情况下就会没有 twrnc 那么直观了，例如一些第三方组件有 xxxStyle 属性，例如 contentContainerStyle，这时 twrnc 就方便很多。

<FlatList style={tw`flex-1`} contentContainerStyle={tw`p-4`} />

而 nativewind 则繁琐许多，下图例子。

// This component has two 'style' props
function ThirdPartyComponent({ style, contentContainerStyle, ...props }) {
  return <FlatList style={style} contentContainerStyle={contentContainerStyle} {...props} />
}

// Call this once at the entry point of your app
remapProps(ThirdPartyComponent, {
  className: 'style',
  contentContainerClassName: 'contentContainerStyle',
})

// Now you can use the component with NativeWind
<ThirdPartyComponent className="p-5" contentContainerClassName="p-2" />

再者，twrnc 可以使用动态变量，例如在 RN 中经常需要处理安全区域，如下写法在 twrnc 就支持，但 nativewind 则不生效。

const { top } = useSafeAreaInsets();

<View style={tw`pt-[${top}]`}> // twrnc 支持

<View className={`pt-[${top}]`}> // nativewind 不支持

tamagui(不推荐)​

我便提一下 tamagui 这个组件库。tamagui 看似很炫酷，但是实际配置的过程异常的繁琐，用起来也没有特别舒服，可以看以下示例代码。

<XStack flex={1} justifyContent="center" alignItems="center" gap="$2">
  <Button size="$3" theme="active">
    Active
  </Button>
  <Button size="$3" variant="outlined">
    Outlined
  </Button>
</XStack>

其效果就是一个容器内包含两个按钮，样式编写上则通过 prop 属性来实现，用过 unocss 的 Attributify Mode 应该会有些许熟悉，但还不那么一样。

并且他的主题系统使用极其的怪，采用 $number 的形式来定义尺寸(官方称 token)，重点是宽高和边距采用相同的 token 效果还不一样，贴个图。

但他的颜色更是一言难尽了，从 color0 到 color11 的效果就如下图

可能是因为我用惯了 Tailwindcss 那套颜色系统，所以很不能理解这套颜色系统，并且在我实际编写组件的过程也是异常的奇怪。

但最让我想吐槽的是官方还为此提供了一个主题系统配置的生成器网站，但只有 tamagui 的赞助者才能够使用，如果想要自己定义一个主题，就需要配置特别多的文件，总之就是很难用就对了。

顺带在贴一张 Provider 嵌套

这里我就不得不提到我为啥一开始选用 tamagui 了(现已迁移到 gluestack-ui)，说实话我是有点后悔的，在一开始选定 UI 库的时候，我是选择 NativeWind 的，但后面无意刷到了 T4-stack (算是被他坑了)，而它所用的便是 tamagui，并且一套代码跑 expo 与 next.js。于是便采用相同的项目结构以及 UI 库了。但事实上在我编写的过程中，想要一套代码就能实现跨三端(web,android,ios) 效果并不佳了，这在下一章便会说到。

gluestack-ui​

首先它与 tamagui 相似，也采用 token 的方式来定义尺寸样式，但该库所对标的 token 设计就是Tailwindcss。此外该 UI 提供 NativeWind 的定制方案，意味着你的项目中可以集成了 NativeWind 用 Tailwindcss 的方式编写组件(类似 shadcn/ui)，并且还在 X 上表示 gluestack-ui + NativeWind 组合就是 React Native 的 shadcn/ui。

因此我个人是比较看好的，不过目前该库目前还处于 Alpha 阶段，可以持续观望中。这个也是我目前最值得推荐的组件库。

React Native 和 Next.js 应用程序共享代码​

如果你想要在 React Native 和 Next.js 应用程序共享代码(UI，逻辑)，你可以考虑使用 solito。该库的写法上会更偏向于 next 的写法，举个例子。

比如说 Image 组件在 RN 写法如下

import { Image } from 'react-native'

<Image
  style={styles.xxx}
  source={{
    uri: 'https://beatgig.com/image.png',
  }}
/>

next.js 的写法

import Image from 'next/image'

<Image src="https://beatgig.com/image.png" width={100} height={100} />

solito 的写法

import { SolitoImage } from 'solito/image'

<SolitoImage src="https://beatgig.com/image.png" height={100} width={100} />

这样 SolitoImage 会判断当前的仓库是 next.js 项目还是 RN 项目对不同的平台进行渲染，以做到同一个组件跨平台的开发，像 Link、useRouter 都是类似用法。

不过当你想要共享代码时，此时就必须得上 monorepo 了，通常目录结构如下图所示，你也可以到这个仓库中查看。

├── apps
│   ├── expo
│   └── next
├── packages
│   └── app
│       ├── features
│       ├── index.ts
│       ├── layouts
│       ├── package.json
│       ├── provider
│       └── screens
├── turbo.json
└── package.json

packages/app 存放主要的公共业务代码，在 next 和 expo 中则直接通过 @xxx/app 子包来导入，具体可看代码，这里就不做过多介绍了。

处理平台差异​

不同平台之间必然会存在一定的开发差异，expo 也提供了相应的解决方案，可以通过给文件添加不同的后缀扩展(.web .android .ios) 以在对应平台执行对应文件，官方文档 Platform specific extensions

一些库分享​

这里只会介绍这个库的用途，至于为什么选择这个而不是其他的，不想做过多的篇幅来解释。如果你用过比这更好的库，也可相互交流。

@gorhom/bottom-sheet​

底部窗口，效果如图

@shopify/flash-list​

一个高性能的列表，可替代 RN 的 FlatList，其中它还支持如下图布局。

react-native-toast-message

toast 消息组件，轻量简单易用。

react-native-gesture-handler

如果你觉得所编写的 RN 应用没有触摸反馈效果，那么可能需要尝试使用 这个库。例如，你可以使用 RectButton 来包装子元素来实现点击按钮波纹反馈效果。如下图所示

此外像拖动组件、滑动删除、放大缩小图片等常见的手势操作，总之这个库都可以实现。

react-native-reanimated

RN 动画库，没啥好说的。

以上组件库可以说基本必装，能为 RN 应用使用体验提升一个档次。

一些案例/组件分析​

分享一些我在编写 RN 中的一些案例。该说不说，RN 的生态是真的可以，很多原生的解决办法几乎都有。

React Navigation​

在这个库你可以实现几乎所有的原生布局，如底部 tabs，左侧抽屉等，expo 是在此基础上进行包装的。

底部 Tabs​

Expo 自带案例，实现效果也简单，这里不在赘述了。

左侧抽屉​

https://reactnavigation.org/assets/navigators/drawer/drawer.mp4

expo 官方所提供的左侧抽屉是带导航的，也就是说你无法同时使用底部选项和左侧抽屉两个布局效果。因此想要同时使用这两种布局，就要使用 Drawer Layout，这里分享我个人的实现过程。

首先，编写 DrawerContainer 组件，代码如下

import { Drawer } from 'react-native-drawer-layout'
import { useDrawerOpen } from '@/atoms/drawer'
import CustomDrawerContent from './CustomDrawerContent'

export function DrawerContainer({ children }: { children: React.ReactNode }) {
  const [open, setOpen] = useDrawerOpen()

  return (
    <Drawer
      open={open}
      onOpen={() => setOpen(true)}
      onClose={() => setOpen(false)}
      swipeEnabled={false}
      renderDrawerContent={() => <CustomDrawerContent></CustomDrawerContent>}
    >
      {children}
    </Drawer>
  )
}

如果想要定制化左侧菜单就必须使用 CustomDrawerContent，这里贴相关代码

import { DrawerContentScrollView, DrawerItem } from '@react-navigation/drawer'

export default function CustomDrawerContent() {
  return (
    <DrawerContentScrollView
      scrollEnabled={false}
      contentContainerStyle={{
        flexGrow: 1,
      }}
    >
      {/* <DrawerItemList {...props} /> */}

      <View className="flex-1 mx-2">

        <DrawerItem
          label="子项 1"
          onPress={() => { }}
        />
        <DrawerItem
          label="子项 2"
          onPress={() => { }}
        />
        {/* ... */}
      </VStack>
    </DrawerContentScrollView>
  )
}

最后在 app/_layout.tsx 中用 DrawerContainer 包装一下 Stack，如下代码。

import { Stack } from 'expo-router'
import { Provider } from '@/provider'
import { DrawerContainer } from '@/components/DrawerContainer'

export default function RootLayout() {
  return (
    <Provider>
      <DrawerContainer>
        <Stack
          screenOptions={{
            headerShown: false,
          }}
        ></Stack>
      </DrawerContainer>
    </Provider>
  )
}

此时就可以用 useDrawerOpen（这里状态库选用 jotai）来控制左侧菜单的展开了。

TabView​

同样的，这个效果在 React Navigation 也是有提供的。但在 expo 中有 react-native-pager-view作为平替，并且更兼容原生，但是 react-native-pager-view 是不支持 Web 端的，因此如何选择就看具体需求了。

固定 Header + tab view​

先看一张图，很多 app 都有这种类似的效果。

这种效果可以使用监听 ScrollY 配合 react-native-reanimated 动画来实现，如果你不想自己实现也可以看看 @codeherence/react-native-header，上图便来自此库。

此外我还留意到 TabbedHeaderPager 这个库（很坑，别用），别看官方 gif 图效果很炫酷，然而实际效果并不达预期，并且十分难用，比如想要更改 tab 样式得像下方这样传递 props 编写。

<TabbedHeaderPager
  tabTextStyle={{
    color: theme.color?.get(),
    padding: 0,
  }}
  tabTextActiveStyle={{
    backgroundColor: 'transparent',
  }}
  tabTextContainerStyle={{
    padding: 0,
  }}
  tabTextContainerActiveStyle={{
    backgroundColor: 'transparent',
  }}
  tabWrapperStyle={{
    paddingVertical: 0,
  }}
  tabUnderlineColor={primaryColor}
  tabsContainerStyle={{
    backgroundColor: bgColor,
    flex: 1,
    maxWidth: Platform.select({
      web: 200,
    }),
    margin: Platform.select({
      web: 'auto',
    }),
  }}
  tabsContainerHorizontalPadding={Platform.select({
    default: 120,
    web: 0,
  })}
  contentContainerStyle={{
    flex: 1,
  }}
/>

RN 原生开发的感悟​

在这段的 RN 开发经历，我还有很多 API 还未尝试，有很多开发上的细节没编写到。篇幅有限，未来如果还有机会编写 RN 项目，再做一些分享(我觉得应该不会有了)。

我曾与安卓开发打过两次交道:

一段是在学习安卓逆向的时候，免不了学习一些基础的原生安卓开发的知识。

另一段是在接触自动化开发的时候，看到了 Auto.js 这个库， 可以使用 JavaScript 和 Node.js 实现小型的安卓应用（不支持 IOS），更多是使用这个库来编写一些脚本类相关的应用。现在回看该库的文档，不由得开始莫名的感叹。

Auto.js Pro 移除了自动化测试、图片处理、消息通知等模块，如果你需要实现的是自动化、工作流工具，则不适合 Auto.js Pro。

在如今内卷的环境下，技术框架变化飞快，文档示例不断完善，服务商们也提供快速搭建应用的模版，又赶上了 AI 热潮，学习一件新东西对于初学者过于容易。随之而来的是开发人员变多，市场需求不足难以满足如此庞大的开发人员，貌似技术对开发人员本身也不是那么的重要？

对于技术人员要如何破局，或许是每位程序员的最值得思考的问题。

本文面向的对象是饱受 TypeORM 折磨的资深用户(说的便是我自己)。只对这两个 ORM 框架从开发体验上进行对比，你也可以到 这里 查看 Prisma 官方对这两个 ORM 框架的对比。

整体对比​

更新频率 & 下载量​

TypeORM 距离上次更新已经过去半年之久了（下图截取自 24 年 1 月 1 日，没想到年初竟然还复活了）

从下载量以及 star 数来看，如今 Prisma 已经超过 TypeORM，这很大一部分的功劳归功于像 Next.js、Nuxt.js 这样的全栈框架。

上图来源 https://npmtrends.com/prisma-vs-typeorm

而在 Nest.js 的 Discord 社区 讨论之中，Prisma 也成为诸多 Nest.js 开发者首选的 ORM 框架，因为它有着更好的开发体验。

在大势所趋之下相信你内心已经有一份属于自己的答案。

文档 & 生态​

从文档的细致程度上 Prisma 比 TypeORM 要清晰详尽。在 Get started 花个数十分钟了解 Prisma 基本使用，到 playground.prisma.io 中在线尝试，到 learn 查看官方所提供的免费教程。

此外 Prisma 不仅支持 js/ts 生态，还支持其他语言。丰富的生态下，加之 Prisma 开发团队的背后是由商业公司维护，无需担心需求得不到解决。

开发体验对比​

在从开发体验上对比之前，我想先说说 TypeORM 都有哪些坑(不足)。

findOne(undefined) 所查询到的却是第一条记录​

首先 TypeORM 有个天坑，你可以在 这个 Issue 中查看详情或查看 这篇文章 是如何破解使用 TypeORM 的 Node.js 应用。

当你使用 userRepository.findOne({ where: { id: null } }) 时，从开发者的预期来看所返回的结果应该为 null 才对，但结果却是大跌眼镜，结果所返回的是 user 表中的第一个数据记录！

你可能会说，这不是 bug 吗？为何官方还不修。事实上确实是 bug，而事实上官方到目前也还没修复该 bug。再结合上文提到的更新频率，哦，那没事了。

目前解决方法则是用 createQueryBuilder().where({ id }).getOne() 平替上一条语句或者确保查询参数不为 undefined。从这也可以看的出，TypeORM 在现今或许并不是一个很好的选择。

synchronize: true 导致数据丢失​

synchronize 表示数据库的结构是否和代码保持同步，官方提及到请不要在生产环境中使用，但在开发阶段这也并不是一个很好的做法。举个例子，有这么一个实体

@Entity()
export class User {
  @PrimaryGeneratedColumn()
  id: number

  @Column()
  name: string
}

当开启了 synchronize: true，并且将 name 更改为 title 时，一旦运行 nest 服务后就会发现原有 name 下的数据全都丢失了！如图所示

因为 TypeORM 针对上述操作的 sql 语句是这样的

ALTER TABLE `user` CHANGE `name` `title` varchar(255) NOT NULL
ALTER TABLE `user` DROP COLUMN `title`
ALTER TABLE `user` ADD `title` varchar(255) NOT NULL

也就是说，当你在开发环境中，修改某个字段（包括名字，属性）时，该字段原有的数据便会清空。

因此针对数据库更新的操作最正确的做法是使用迁移(migrate)。

接入成本​

在 Nest 项目中，Prisma 的接入成本远比 TypeORM 来的容易许多。

相信你一定有在 xxx.module.ts 中在 imports 中导入 TypeOrmModule.forFeature([xxxEntity]) 的经历。就像下面代码这样：

@Module({
  imports: [TypeOrmModule.forFeature([UserEntity])],
  controllers: [UserController],
  providers: [UserService],
  exports: [TypeOrmModule, UserService],
})
export class UserModule {}

对于初学者而言，很大程度上会忘记导入 xxxEntity，就会出现这样的报错

Potential solutions:
 - Is UserModule a valid NestJS module?
 - If "UserEntityRepository" is a provider, is it part of the current UserModule?
 - If "UserEntityRepository" is exported from a separate @Module, is that module imported within UserModule?
   @Module({
     imports: [ /* the Module containing "UserEntityRepository" */ ]
   })

Error: Nest can't resolve dependencies of the userService (?). Please make sure that the argument "UserEntityRepository" at index [0] is available in the UserModule context.

此外这还不是最繁琐的，你还需要再各个 service 中，通过下面的代码来注入 userRepository。

@InjectRepository(UserEntity)
private readonly userRepository: Repository<UserEntity>

一旦实体一多，要注入的 Repository 也就更多，无疑不是对开发者心智负担的加深。

再来看看 Prisma 是怎么导入的，你可以使用 nestjs-prisma 或者按照官方文档中创建 PrismaService。

然后在 service 上，注入 PrismaService 后，就可以通过 this.prisma[model] 来调用模型(实体) ，就像这样

import { Injectable } from '@nestjs/common'
import { PrismaService } from 'nestjs-prisma'

@Injectable()
export class AppService {
  constructor(private prisma: PrismaService) {}

  users() {
    return this.prisma.user.findMany()
  }

  user(userId: string) {
    return this.prisma.user.findUnique({
      where: { id: userId },
    })
  }
}

哪怕创建其他新的实体，只需要重新生成 PrismaClient，都无需再导入额外服务，this.prisma 便能操作所有与数据库相关的 api。

更好的类型安全​

Prisma 的贡献者中有 ts-toolbelt 的作者，正因此 Prisma 的类型推导十分强大，能够自动生成几乎所有的类型。

而反观 TypeORM 虽说使用 Typescript 所编写，但它的类型推导真是一言难尽。我举几个例子：

在 TypeORM 中，你需要 select 选择某个实体的几个字段，你可以这么写

你会发现 post 对象的类型提示依旧还是 postEntity，没有任何变化。但从开发者的体验角度而言，既然我选择查询 id 和 title 两个字段，那么你所返回的 post 类型应该也只有 id 与 title 才更符合预期而后续代码中由于允许 post 有 body 属性提示，那么 post.body 为 null 这样不必要的结果。

再来看看 Prisma，你就会发现 post 对象的类型提示信息才符合开发者的预期。像这样的细节在 Prisma 有非常多。

这还不是最关键的，TypeORM 通常需要使用 createQueryBuilder 方法来构造 sql 语句来满足开发者所要查询的预期。而当你使用了该方法，你就会发现你所编写的代码与 js 无疑，我贴几张图给大伙看看。

这无疑会诱发一些潜在 bug，我就多次因为要 select 某表中的某个字段，却因拼写错误导致查询失败。

创建实体​

在 TypeORM 中，假设你要新增一条 User 记录，你通常需要这么做

const newUser = new User()
newUser.name = 'kuizuo'
newUser.email = 'hi@kuizuo.me'
const user = userRepository.save(newUser)

当然你可以对 User 实体中做点手脚，像下面这样加一个构造函数

@Entity()
export class User {
  @PrimaryGeneratedColumn()
  id: number

  @Column({ unique: true })
  username: string

  @Column()
  email: string

  constructor(partial?: Partial<UserEntity>) {
    Object.assign(this, partial)
  }
}

const newUser = new User({
  name: 'kuizuo',
  email: 'hi@kuizuo.me',
})
const user = userRepository.save(newUser)

于是你就可以传递一个 js 对象到 User 实体，而不是 newUser.xxx = xxx 像 Java 版的写法。

而要是涉及到多个关联的数据，往往需要先查询到关联数据，然后再像上面这样赋值+保存。这里就不展开了，使用过 TypeORM 的应该深有体会。

而在 Prisma 中，绝大多数的操作你都只需要一条代码语句外加一个对象结构，像上述 TypeORM 的操作对应 Prisma 的代码语句如下

const user = await prisma.user.create({
  data: {
    name: 'kuizuo',
    email: 'hi@kuizuo.me',
  },
})

根据条件来创建还是更新​

在数据库中操作经常需要判断数据库中是否有某条记录，以此来决定是更改该记录还是创建新的一条记录，而在 Prisma 中，完全可以使用 upsert，就像下面这样

const user = await prisma.user.upsert({
  where: { id: 1 },
  update: { email: 'example@prisma.io' },
  create: { email: 'example@prisma.io' },
})

聚合函数​

在 TypeORM 中，假设你需要使用聚合函数来查询的话，通常会这么写

const raw = await this.userRepository
  .createQueryBuilder('user')
  .select('SUM(user.id)', 'sum')
  .getRawOne()

const sum = raw.sum

如果只是像上面这样，单纯查询 sum，那么 raw 的值是 { sum: 1 } , 但最要命的就是 select 配合 getRawOne 还要额外查询 user 实体的属性，所得到的结果就像这样

const raw = await this.userRepository
  .createQueryBuilder('user')
  .select('SUM(user.id)', 'sum')
  .addSelect('user')
  .where('user.id = :id', { id: 1 })
  .getRawOne()

{
	user_id: 1,
	user_name: 'kuizuo',
	user_email： 'hi@kuizuo.me',
	sum: '1'
}

所有 user 的属性都会带有 user_ 前缀，这看上去有点不是那么合理，但如果考虑要联表查询的情况下，就会存在相同名称的字段，通过添加表名(别名)前缀就可以避免这种情况，这样来看貌似又有点合理了。

但还是回到熟悉的类型安全，这里的所返回的 raw 对象是个 any 类型，一样不会有任何提示。

而在 Prisma 中，提供了 专门用于聚合的方法 aggregate，可以特别轻松的实现聚合函数查询。

const minMaxAge = await prisma.user.aggregate({
  _count: {
    _all: true,
  },
  _max: {
    profileViews: true,
  },
  _min: {
    profileViews: true,
  },
})

{
  _count: { _all: 29 },
  _max: { profileViews: 90 },
  _min: { profileViews: 0 }
}

看到这里，你若是长期使用 TypeORM 的用户必定会感同身受如此糟糕的体验。那种开发体验真的是无法用言语来形容的。

Prisma 生态​

分页​

在 Prisma 你要实现分页，只需要在 prismaClient 继承 prisma-extension-pagination 这个库。就可像下面这样，便可在 model 中使用paginate方法来实现分页，如下代码。

import { PrismaClient } from '@prisma/client'
import { pagination } from 'prisma-extension-pagination'

const prisma = new PrismaClient().$extends(pagination())

const [users, meta] = prisma.user
  .paginate()
  .withPages({
    limit: 10,
    page: 2,
    includePageCount: true,
  });

// meta contains the following
{
  currentPage: 2,
  isFirstPage: false,
  isLastPage: false,
  previousPage: 1,
  nextPage: 3,
  pageCount: 10, // the number of pages is calculated
  totalCount: 100, // the total number of results is calculated
}

支持页数(page)或光标(cursor)。

而在 TypeORM 你通常需要自己封装一个 paginate方法，就如下面代码所示（以下写法借用 nestjs-typeorm-paginate）

async function paginate<T>(
  queryBuilder: SelectQueryBuilder<T>,
  options: IPaginationOptions,
): Promise<Pagination<T>> {
  const { page, limit } = options

  queryBuilder.take(limit).skip((page - 1) * limit)

  const [items, total] = await queryBuilder.getManyAndCount()

  return createPaginationObject<T>({
    items,
    totalItems: total,
    currentPage: page,
    limit,
  })
}

// example
const queryBuilder = userRepository.createQueryBuilder('user')
const { items, meta } = paginate(queryBuilder, { page, limit })

当然也可以自定义userRepository，为其添加 paginate 方法，支持链式调用。但这无疑增添了开发成本。

根据 Schema 自动生成数据验证​

得益于 Prisma 强大的数据建模 dsl，通过 generators 生成我们所需要的内容（文档，类型），比如可以使用 zod-prisma-types 根据 Schema 生成 zod 验证器**。**

举个例子，可以为 schema.prisma 添加一条 generator，长下面这样

generator client {
  provider = "prisma-client-js"
  output   = "./client"
}

generator zod {
  provider                         = "zod-prisma-types"
  output                           = "./zod"
  createModelTypes                 = true
	// ...rest of config
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model User {
  id         String      @id @default(uuid())
  email      String      @unique
  name       String?
}

执行构建命令后，这将会自动生成 zod/index.ts 文件，将包含 UserSchema 信息，其中片段代码如下

export const UserSchema = z.object({
  id: z.string().uuid(),
  email: z.string(),
  name: z.string().nullable(),
})

export type User = z.infer<typeof UserSchema>

再通过 createZodDto，将 zod 验证器转化为 dto 类，就像下面这样

当然你可能并不想在 nestjs 项目中使用 zod，而是希望使用传统的 class-validator 来编写 dto。可以使用社区提供的 prisma-class-generator 根据已有 model 生成 dto。

合理来说，Prisma 并不是一个传统的 ORM，它的工作原理并不是将表映射到编程语言中的模型类，为处理关系数据库提供了一种面向对象的方式。而是在 Prisma Schema 中定义模型。在应用程序代码中，您可以使用 Prisma Client 以类型安全的方式读取和写入数据库中的数据，而无需管理复杂模型实例的开销。

总而言之，你若想要更好的类型，简洁的实体声明语法，况且带有可视化桌面端应用，以及更好的生态完备，那么你就应该选 Prisma。

总结​

在写这篇文章时，我也是彻底的将 Nestjs 项目中由 TypeORM 迁移到 Prisma ，这期间给我最大的变化就是在极少的代码量却又能实现强大的功能。许多涉及多表的 CRUD操作可以通过一条简洁的表达式来完成，而在使用 TypeORM 时，常常需要编写繁琐臃肿的 queryBuilder。

TypeORM 有种被 nestjs 深度绑定的模样，一提到 TypeORM，想必第一印象就是 Nestjs 中所用到的 ORM 框架。然而，Prisma 却不同，是一个全能通用的选择，可以在任何的 js/ts 框架中使用。

从开发体验的角度不接受任何选择 TypeORM 的反驳，有了更优优秀的选择，便不愿意也不可能在回去了。如果你还未尝试过 Prisma，我强烈建议你亲身体验一番。

不过如今都大四了，也确实是要考虑实习的事了。我想结合我自身情况，谈谈我是怎么看待工作或者往远点说职业规划方面的想法。

一些经历​

工作经历​

我目前一共有 3 段工作经历

1. 休学一年在厦门本地某工作室(共4人)与他人创业。 2021.1 ~ 2022.1
2. 在北京的一家公司(规模不大)远程实习。 2022.8 ~ 2022.10
3. 在 3R 教室 兼任助教与开发组成员。 2023.1 ~ 2023.12

事实上，对我而言也仅有休学的那一段才能算是工作，而其他两者从年限与工作性质来看不能算是一份真正的工作。但也不能说不是，至少也替别人做过事、签过合同、领过工资的。

不过我想稍微提提我是怎么找到这三个工作的，或者说这三份工作是怎么找到我的 -> 全靠分享

我不止说过一次分享的重要性，我的第一份工作就是在网络分享了一个大学生自动完成视频、作业的程序，恰好被我当地一个工作室的同事看到，寻求我能否改进功能一同合作，于是一拍即可，便开始休学。

剩余的两个工作同样也是，一个契机是我当时正好在研究 Strapi 编写了一篇文章，这家公司恰好用到这门技术；而 3R教室则是因为创始人所用的与我博客相同的网站生成器 Docusaurus 在这个机缘下认识的，后来创始人创业开了3R教室，我也就利用业余时间在其中扮演助教身份，赚个零花钱。（其实我很热心肠的，哪怕我不当助教，只要时间允许的情况下，你有问题问我也会尽数回答）

接单经历​

同样的，分享也能很大程度上提升你接单的资本。

我并非想要炫耀什么，而是分享实实在在给我带来了很多好处，我希望你能够分享一些内容，一些见解心得，哪怕是一些笔记、对他人问题的回复，都可能给你带来一些意想不到的好处。

我就有一个同学将自己的笔记、课设以及每次专业课期末考试的文档放到 CSDN 上（没错就是那个 IT 界的毒瘤），现在这不到期末了嘛，他的私信就有一堆人找他写课设啥的。

回归到正题，我接过单不多也不少，绝大多数是那种对我而言挺简单的问题，但对于一些人而言就比较困难。例如前几天一个例子，我编写过 js-deobfuscator 一个 js 混淆还原的工具，正好有人需要将一份混淆代码还原出来，于是寻求我的帮助，发了个红包给我。有时哪怕只是回答别人一个问题，甚至都可能会收到来自他人的红包。想想看，你在技术群里是不是有过这个现象。

还有一个网站的单子我印象很深，是一个用于销售流量、虚拟会员等商品的网站，不同与普通的商城系统，充值是通过卡密，使用卡密到特定的网站上使用。当时一个网站全套 5000，客户也算熟人了，还帮我推荐几个人购买，相当于这一套网站(模版)，帮我赚了几 w，还省去我很多开发成本，后续我都无偿给他提供技术服务。

事实上至少现在为止我并不是很喜欢接单，也很少主动接单。小的单（也可叫零活）通常以一顿夜宵作为回报或是看在人情的份上；而大的单（通常为外包单），通常要求交付时间快，很多时候只为了更快的完成功能，而不考虑代码质量。并且通常没有维护性可言，就更别说写测试和重构了。写久了，代码虽然写的是快了，但堆屎山的速度都堪比屎壳郎了。代码能力的提升反而不是很大。

在我看来当因某种目的收了他的钱财时，往往就要花费时间精力去完成这个目的，而从我内心上很难平衡这点。所以只要我不收钱，我就可以不做事了（bushi

赚钱经历​

我赚的第一桶金其实还不是我工作，在上大学前我已经赚过对我两桶金了，还全都是依靠网络上的资源，而非现实打工。一次是初三当时向别人学习如何刷钻以及购买钻卡来接单帮别人刷钻，另一个是作为线报群群主（现如今更多的称之为羊毛群，但我更愿称撸界），发布一些活动和教程通过拉人头引流赚钱。而也是再次契机之下，学会了开发(定制)软件。

这并非本文重点，因此我并不想过多介绍，但或许这会作为后面的铺垫。

不过我还是想说：赚钱不易。我现在回看我过去的一些经历，只能说运气成分很大，而又恰好在风口之中。在如今的互联网环境下，想要复刻曾经的路, 无疑是死路一条。

为何不实习？​

背景介绍完了，那就来说说实习的事情，为何我都大四了，还不找实习？

不是不找，而是很难找到满意的。我在今年暑期的时候有尝试找过，投过几家大厂，无一例外，了无音讯。这对我当时而言，打击还蛮大的。因为三流学校出身，确实很难过（双关），加之没人内推，海投基本上是没希望的。

如今前端的职位卷之又卷，僧多粥少，在厦门一些中小公司所提供的前端实习待遇（薪资大约在 3k~4k），况且对自身的提升并不是特别大，在我不是一笔性价比划得来的买卖。

反观学校的情况那可就更头疼了，你敢相信在大四上最该实习的时候，极为不合理的教案却还要给学生安排课程，还是专业课的那种，以下我的课表。

此外，我还需要重修当初因休学而没去考试的几门课程（还挺多的，重修费还交了我不少😢），导致我最后一场考试时间是在 12月中旬。还是强调那一点，我不希望工作与学业这两者同时进行。关于这学校的诸多不满，待我毕业后我一定要说说，感受什么叫中国的私立大学。

此外还有一点，也是我不想提及的一点，这段期间我是处于“监视”状态，内心总悬着一个不知何时爆炸的炸弹，生怕突然爆炸将会打乱我的行程。

好在如今期限已到，心里悬着的一块石头终于放下来了，如释重负。

于是在上述的因素下，今年下半年我就不想找实习了。

为何又想实习了？​

最主要的一点就是以我目前学生(应届生)的身份，是可以有机会争取到一份好的实习的，乃至是大厂的实习。

其次是我并没有一个很好的项目演进经历，看完我的一些工作经历不难发现我所待的公司/工作室的体量都不大，甚至我到现在都没真正体验过打卡上班（当然我也希望不要有）。而这就是小厂或者初创公司的同病，各个流程所要负责的任务很模糊。我当时休学和他人创业工作，基本上都是我一人负责项目开发；第二个远程实习也是我当时主动退出的，因为工作形式与接单无疑；第三个就不用多说了。

尤其是在技术层面的团队协作之中，还缺乏相当多的实践经验。所以在自我分析下，为了学习某些只在公司才能学到的东西，就非常有必要到大公司去一趟。

我大概率以后是不太可能再考虑坐班，所以这或许是我仅有为数不多的上班经历了。不过我想既便真正要开始打卡上班，要开始适应国内 996，未来我铁定会后悔有过这段历程。

那么该怎么找呢？​

那么在如今就业形势如此严峻的时代，我又该如何找工作？

关于这点我其实并没有什么很好的经验分享，这也算是我首次主动找工作。不过我可以肯定的一点是，只单靠海投与某些招聘软件，想要拿到一份心意的 offer 很难。若是能通过一些关系，牵一条线（走内推），才是最佳选择，所以多积攒人脉交际圈是很有必要的。

这一部分我想待我后续找到工作后，再来做个心得分享也不为迟。（不说了，我去准备项目与简历去了）

远程工作​

电鸭的sologen：只工作，不上班。很好表明远程工作的意图。

远程工作（remote work）是我当下认为最具性价比的工作形式，你可以过着四五线城市的生活水平而不用考虑一线城市的房租与消费，却赚取一线城市的薪资。往大点说就是挣美元花人民币。

但是远程工作并非多数人想的那么轻松的，很多人对远程工作有个误区，就是可以自由决定上班时间，很自由。其实不是的，不用上下班通勤，那就把通勤的时间拿来工作。没有额外房补开销，那就拿来压低工资。而该开的会还是得开，说白了就是换个地方上班，懒床是睡不了一点的，好一点的是冬天起来不用遭受寒风的洗礼罢了。

有的远程工作还会要求你记录每个时间段(细到每小时)你都做了哪些工作，我暑期的就有一份我老师推荐的远程工作(实习)就是这样，我就没干了。要论自由，接单/自由职业是最自由的，项目进度、时间都由你自己把握。

此外还有一点就是技术栈的因素。我并没有跟随国内的主流的 Web 开发技术栈去学习什么 Java，也庆幸还好当初认为 Java 这门语言繁琐的要死，让我转变使用 JS/TS 来进行 Web 全栈的开发，而如今的重心也是在 JS/TS。

而这套技术栈在国外的远程工作的岗位占比很大，一些初创公司也会采用这套技术栈。而我本身学的就是 JS/TS，自身优势反而更能体现出来。但反观在国内绝大多数公司我也就是老老实实做前端的那种。况且如果只想靠国内的主流传统的技术栈而去争取一个远程岗位，我认为当下还是很难实现的。就国内的职场环境下，如今工作都难找了，就别说本身岗位就少的远程工作了。

正常坐班​

退而其次，那就正常上下班通勤，而这又有的抉择了。就以我自身举例把，我老家福建宁德且我在厦门某三流大学读书，意味着我只要在福建本地找工作，就可以过的相对来说舒服，人脉资源、衣食住行都不用过多考虑。但倘若选择在外打拼，意味着可能要适应陌生的城市生活，建立起新的人际网络，面对未知的困难和挑战。而这其中所能利用的、所要遭受的，都得由自个儿来承担。

今年冬至的时候我与家里人商讨过这个问题，家里人的意见更多偏向于留在本省，只求我稳稳当当，脚踏实地。因为我从小到大独立性很差，加上我确实有那么亿点宅，到外面恐怕是吃不消。所以在他们眼里哪怕在本省薪资不是令我那么满意，但至少可以过一种相对舒适的生活。而我自己则认为有必要去外面见见世面，有时候很多苦只有自己吃过才知道有苦。

不过最终如何选择，还得取决于我自己。这对于多数人也是值得花时间思考的。

最终如果选择重归故里，那么一开始就身在其中是否会更好？又何必在外漂泊，独自承受着一切。

我对打工/上班的看法​

我经常拿我高考结束的那个暑假来做例子，我的一些高中同学去当外卖骑手、餐厅服务员，将他们的假期时间拿来打工赚钱，而我却埋头苦干的学习编程(易语言)，以兴趣驱使我学习一门技术。

或许是因为有过几段赚钱经历，加上家境和个人意愿，所以至今为止我都不可能会去从事这种回报率不高，或者说没有“未来”的工作。与其打工/上班，尤其是耗费大量时间与体力劳动的，不如将时间拿来提升自己综合能力。（个人观点，或许有些极端）

可能是由于受自由的影响加上年轻有精力折腾，同时自己又是那么不走”寻常路“、不遵循“规则”的人。所以像那种安稳平淡，重复劳动的工作，如体制/编制内的职业就不太那么感冒。

但从现实是没人想打工/上班，却依旧有人从事这些工作。绝大多数打工人别无选择，因生活所迫，只得忍受和抱怨打工/上班的痛苦，却又寄人篱下。

期望的工作​

要说不工作是不可能的（但打工是不可能的），或许是因为这几年的一些工作经历有关，导致我有点习惯了远程，加上网间传闻 996 的压力下，我现在对坐班甚至还有些厌恶。对我最理想的工作环境就是能够自我在决定在某个时间点是否工作，例如在工作日放假，在节假日上班。

接单虽说也是，那这毕竟不是一份正经的工作，更多意义上来说是份兼职。更多是作为一时之需，接单又不可能接一辈子（搞得工作能工作一辈子似得）。

而我想说的是做个自由职业者，在细一点也就是独立开发者。但是现在来看这并非易事，不仅需要一定的技术能力和营销水平，最关键的想法就已经让绝大多数人对这份职业扼杀在摇篮中。

现状​

首先我对自己的生活方式定义是：偏向于自发的能量爆发，而不是有条理的持续努力。

今年我的 github contributions 出现过了几次长时间的空缺，那段期间我基本上没有在写代码，而是将心思用在其他事情上。例如只打游戏（好在游戏如今也是戒了）、只想摆烂（好在是摆的有点多了）、只想复习（好在该考的试都已经考了）。这就导致很多时候我会将全部精力专注在某件事情上，而抛弃其他与之无关的事情。

这也就导致了我很难养成一个良好的习惯，我的生物钟也因此而发生巨变。贴一张极为离谱的作息

总之持之以恒在我这还不存在过，多数的开始是因一腔热血，而最后结束时却草草了事。

我想是是过度的自由造就了这般现状，想要解决这个问题，坐班可能还真可以。

或许是因为比同龄人提前踏入过社会，有过几段工作经验，所以在就业形势严峻的时代，其实我反倒不是那么慌张。

何况目前经济状态也还算正常，哪怕不找工作也足够养活我自己好一整子。至少相比同龄人下，我已经挺富裕了。也没必要搞个打赏在自己的网站或项目上放置收款二维码等无关项目信息。对我而言，编写这些的目的不是为了接某个单，赚个打赏费，更多是一时兴起，分享给有需要的人，希望让其更为纯粹一些，仅此而已。

我对赚钱的态度也很简单，悦己便可（做点让自己愉悦的事情），数额能够维持自身生存便足够了。不过现在我还没开始到还贷的境地，或许只有压迫感来临时，才会让我激起对金钱的渴望，改变对金钱的态度。

取悦自己，生活最好的心态。

感慨​

接触 web 开发算下整整两年半的时间，在这期间我并没有很好地扩张自己的技术面。在折腾方面确实不如以往，学习主动性也欠缺许多。不同于一开始所学习那样，喜欢瞎捣鼓，看到某个东西就会想尝试安装。

明年也就 24 岁了，面对即将到来的本命年，下一个阶段的走向其实很迷茫，面对我的是留学还是工作，我到现在都没有定数…

虽说我现在大四还在读，但其实我已经比同龄人晚毕业 1-2 年了（此时怀着感慨的泪水不禁流下）。心智上还保留着校园少年的青雉 ，同时也多了份成熟的稳重。

有过这些经历让我收获了更为珍贵的经验和独特的成长路径，我想未来的日子必定是丰富多彩的。

往年回顾​

• 2022 · 逆向到Web开发
• 2021 · 休学一年
• 2020 · 编程之旅-起点

思考​

此时不妨思考一个问题，现在以下几个接口，你会怎么去设计 url 路径？

• 查询文章
• 查看文章详情
• 创建文章
• 更新文章
• 删除文章
• 查看我的文章
• 查看他人的文章

前 5 个接口想必不难设计，这边就给出标准答案。

• 查询文章 GET /articles
• 查看某篇文章详情 GET /articles/:id
• 创建文章 POST /articles/
• 更新文章 PUT /articles/:id
• 删除文章 DELETE /articles/:id

当然，我相信肯定也有GET /article—list POST /add-article 这样的答案，不过这些不在 restful api 风格的范畴，就不考虑了。

而这时 查看我的文章 或许就需要稍加思考，或许你会有以下几种方式

• GET /my-articles 从资源角度来看肯定不好，因为此时在 url 不能很直观地体现请求资源，同时在控制器文件(controller) 就与 article 分离了，并且还占用了 / 下路径。
• GET /articles/mine 则又不那么遵循 restful api 风格，挺违和的。

那么这时不妨遵循 资源从属关系，在这里 文章所属的对象就用户，因此查看他人的文章可以这么设计GET /users/:userId/articles 获取特定用户（userId）的文章列表。

而 查看我的文章 同样也可用此 URL，只需将 userId 更改为自己的便可。从 api 的 URL 来看是很舒服了，但是从代码开发的角度上问题又有了问题了。。。

对于 user 资源，是不是也有查询，创建，更新，删除等接口，即 查询用户 GET /users，创建用户POST /users/ 等等。。

我是不是就需要在 user 这么重要的资源控制器上去添加一些其他方法，所对应的代码就如下所示

@Controller('users')
export class UserController {
  constructor(private userService: UserService, private articleService: ArticleService) {}

  @Get()
  async list(@Query() dto: UserQueryDto) {
    return this.userService.findAll(dto)
  }

  @Get(':id')
  async info(@Param('id') id: number) {
    return this.userService.findOne(id)
  }

  @Post()
  async create(@Body() dto: UserCreateDto) {
    await this.userService.create(dto)
  }

  // 省略有关 User 部分接口，以下是其他 user 下的资源接口

  @Get(':userId/articles')
  async articles(@Param('userId') userId: number) {
    return this.userService.findAll(userId, articlesId)
  }

  @Get(':userId/articles/:articlesId')
  async articles(@Param('userId') userId: number, @Param('articlesId') articlesId: number) {
    return this.articleService.find(userId, articlesId)
  }
}

换做是我，肯定不会希望将用户的代码与文章的代码混杂在一起。解决办法也是有的，可以额外创建一个新的 UserController 文件，专门用于获取用户下的资源（这里指 article），这样可以 即与原有针对 user 资源进行解耦，有可以有比较清晰接口分类。