如何技术探索与实践？——一个经历过公司倒闭的前端开发的真实复盘
去年十月，我坐在老家阳台上，一边啃着刚蒸好的红薯，一边盯着电脑屏幕上“项目终止”的邮件。那一刻，我突然意识到：技术探索，不是选修课，而是生存必需品。
一、从“稳定”到“清零”：一场猝不及防的崩塌
时间倒回2023年10月17日，下午3点28分。
我正用 VS Code 调一个 React 组件的响应式布局，手机突然震动。是 HR 的微信消息：“小陈，老板在开紧急会议，可能……有变动。”
我的心猛地一沉。那会儿我在一家做 SaaS 工具的创业公司干了快一年，月薪15k，远程办公，人在湖南老家。省了北京3500块的房租，还能每天陪爸妈吃晚饭，日子过得挺踏实。
但“创业公司”这四个字，就像悬在头顶的达摩克利斯之剑。
两小时后，全员 Zoom 会议。CTO 红着眼说：“融资没到位，账上撑不过下个月。大家……今天起暂停工作。”
我关掉视频，瘫在椅子上，手心全是汗。老婆在厨房喊：“饭好了！”我应了一声，却动弹不得。脑子里反复回放一句话：“你连个 GitHub 都没更新半年，除了写业务代码，还会啥？”
那天晚上，我翻出自己的简历，发现除了“熟练使用 Vue/React”“熟悉 Webpack”这些套话，几乎没什么能证明自己“技术深度”的东西。更可怕的是，我连最近半年前端圈在卷什么都说不清楚——微前端？低代码？Rust+WASM？全靠刷知乎和掘金碎片化了解，根本没动手。
那一刻我才懂：技术探索，不是为了“显得很牛”，而是为了在风暴来临时，手里还有桨。
二、回到“老家模式”：没有会议室，只有阳台和键盘
公司倒闭后，我给自己定了个“30天重启计划”。
第一件事：把工位搬回老家阳台。一张折叠桌，一把二手人体工学椅（闲鱼淘的，280块），一台用了五年的 MacBook Pro（风扇声像拖拉机）。老婆笑我：“你这是要当数字游民还是山顶洞人？”
我说：“我要重新学会‘探索’。”
但问题来了——怎么探索？从哪开始？
很多人以为“技术探索”就是读源码、造轮子、写技术博客。听起来很酷，但对一个刚失业、还要还房贷的人来说，太奢侈了。我需要的是低成本、高反馈、能变现的探索路径。
于是，我做了三件事：
1. 用“工具”代替“理论”，先解决实际问题
我不再死磕“为什么 Vite 比 Webpack 快”，而是直接问自己：“我现在最烦什么？”
答案是：每次写组件都要重复写样式、逻辑、测试用例，效率低到想砸键盘。
于是我决定：做一个内部工具，自动生成 React 组件模板。
目标很简单：输入组件名，自动输出带 Storybook、TypeScript 类型、Jest 测试骨架的完整目录结构。
我花了三天，用 Node.js + Commander 写了个 CLI 工具。虽然粗糙，但真的省了我每天半小时的重复劳动。更重要的是，在这个过程中，我被迫去查了文件系统 API、模板字符串渲染、命令行参数解析——这些以前觉得“用不到”的知识，突然变得鲜活起来。
后来我把这个工具开源了，Star 不多，但有位网友留言：“你这个生成器救了我司新人培训流程。”那一刻，我第一次觉得：技术探索，不一定要颠覆世界，能帮到一个人就够了。
2. 把“开发心得”写成“可复用的经验包”
以前写代码，遇到坑就 Google 一下，解决完就忘。这次我逼自己：每解决一个问题，必须写成一篇“微型笔记”。
比如上周五晚上，我调试一个 Next.js 的 ISR（Incremental Static Regeneration）缓存问题，折腾到凌晨两点。以前可能骂一句“Next.js 真坑”就睡了。但这次，我打开 Notion，新建一页，标题就叫《Next.js ISR 在 Vercel 上失效的 3 个排查点》。
内容包括：
- 缓存头是否被 CDN 覆盖
- getStaticProps 是否返回了 fallback: false
- Vercel 的 build logs 里有没有 warning
写完后，我顺手发到团队 Slack（虽然团队已解散，但我建了个“前同事互助群”）。没想到第二天，前同事老王回我：“兄弟，你这笔记救了我！我们新项目也卡这儿了。”
原来，开发心得不是“个人日记”，而是可以流通的“技术货币”。
3. 借力 AI，但不做“提示词搬运工”
说到工具，不得不提 通义千问。
去年11月，我开始用它辅助开发。但很快发现：如果只是问“怎么实现一个防抖函数”，那和查 MDN 没区别。真正的价值在于——让它帮我“扩展思考边界”。
举个例子：我想优化一个表单提交的性能，但不知道从哪下手。我问通义千问：
“作为一个前端，如何系统性地分析一个 React 表单的性能瓶颈？请给出可执行的步骤和工具链建议。”
它回了我一套方案：
- 用 React DevTools 的 Profiler 定位重渲染组件
- 用 Chrome Performance 面板看主线程阻塞
- 考虑用
useMemo和useCallback优化子组件 - 对于大表单，试试将状态拆分为多个 context
- 如果涉及复杂计算，考虑 Web Worker
这些建议未必全对，但它给了我一个“检查清单”。我照着做，果然发现一个隐藏的 useEffect 无限循环问题。
更关键的是，我学会了反问 AI：“你提到的 Web Worker 方案，在 React 中如何安全地管理 worker 生命周期？”——这种追问，逼我深入理解底层机制。
AI 不是答案机，而是“思维脚手架”。你得自己爬上去，才能看到风景。
三、从“瞎摸索”到“有策略”：我的技术探索框架
经过这几个月的折腾，我总结出一套适合普通开发者的“技术探索实践框架”。它不炫技，但能落地。
第一层：问题驱动（Problem-Driven）
别一上来就学“微前端架构”。问问自己：
- 最近哪个任务让你加班到崩溃？
- 哪段代码你每次看到都想删掉重写？
- 哪个需求因为技术限制只能妥协？
痛点，是最好的探索起点。
我现在的原则是：每周至少解决一个“让自己烦躁的小问题”，哪怕只是写个 VS Code 插件自动格式化 JSON。
第二层：工具闭环（Tooling Loop）
探索不能停留在“知道”，要形成“用-改-分享”的闭环。
比如我最近在研究 Vite 插件开发，不是为了成为 Vite 专家，而是因为：
- 我们项目需要自定义资源加载逻辑
- 现有插件不满足需求
- 自己写一个，能控制缓存策略
写完后，我把它封装成 npm 包，文档写清楚适用场景。虽然下载量只有几十，但这个过程让我真正理解了 Vite 的插件机制，而不是背面试题。
第三层：输出倒逼（Output-Forced）
光看不练假把式。我给自己定的规矩：
- 每学一个新概念，必须写一段可运行的 demo
- 每解决一个 bug，必须记录复现步骤和根因
- 每尝试一个工具，必须对比“不用它时”的效率差异
输出不是为了炫耀，而是为了验证自己是否真懂。
四、那些没人告诉你的“暗坑”
当然，探索路上全是坑。分享几个血泪教训：
1. 别陷入“工具崇拜”
有段时间我疯狂追新：SvelteKit、Qwik、SolidJS……每个都试一遍，结果项目没推进，反而焦虑爆棚。后来我悟了：工具是手段，不是目的。 除非你的业务场景真的需要它，否则别为“潮流”买单。
2. 别把“探索”当成逃避
失业初期，我一度沉迷造轮子，美其名曰“技术提升”，其实是逃避投简历的恐惧。直到老婆问我：“你做的这个状态管理库，能换钱吗？”我才醒过来。
探索必须服务于生存，否则就是自我感动。
3. 别忽视“非技术因素”
技术再强，不懂沟通、不会写文档、不理解业务，一样被淘汰。我现在每天花 30 分钟读产品需求文档，甚至主动约产品经理聊用户故事。技术探索的终点，是更好地服务人，而不是机器。
五、现在，以及未来
写这篇文章时，是2024年4月12日，周五晚上9点。我刚结束一个远程面试，对方是一家做开发者工具的 startup，给的 offer 是 22k，支持 fully remote。
谈薪时，HR 问：“你这段时间都在做什么？”
我没说“我在学习 Rust”，也没吹“我研究了最新前端框架”。我说：
“我做了三件事：第一，优化了自己开发流程的工具链，效率提升 40%；第二，把踩过的坑整理成团队知识库，减少新人上手成本；第三，用 AI 辅助 code review，提前发现 15% 的潜在 bug。这些，都是我能带到贵司的。”
她眼睛亮了。
技术探索的价值，不在于你掌握了多前沿的技术，而在于你能否把探索转化为生产力。
结语：探索，是为了在不确定中锚定自己
回看那段公司倒闭的日子，我其实很感谢它。
它逼我从“功能实现者”变成“问题解决者”，从“被动接需求”变成“主动找痛点”。技术探索不再是 KPI，而是生存本能。
如果你也在焦虑：该学什么？怎么学？值不值得？
我的答案很简单：
别等“有时间”再探索。就在你下一个 PR 里，加一行注释解释为什么这么写；就在你下一个 bug 里，多问一句“为什么会这样”；就在你下一个工具选择里，多试一种可能性。
探索不在远方，就在你敲下的每一行代码里。
最后，送大家一句我贴在显示器边的话：
“工具会过时，框架会淘汰，但解决问题的能力，永远稀缺。”
共勉。
—— 一个在老家阳台敲代码的前端，2024年4月
评论 0