“想问一下大家现在都在做些什么呢”——这句话我最近在好几个技术社群里都看到过不是那种寒暄式的随口一问而是带着一点迷茫、一点好奇、一点想对表的意思。说实话我自己也经常在深夜盯着屏幕的时候冒出这个念头。做技术这行或者说做内容、做产品、做自由职业的朋友们大家各自埋头在自己的战壕里偶尔抬头看看周围发现别人跑的方向跟自己完全不一样那种既焦虑又兴奋的感觉只有经历过的人才懂。这篇文章就不讲什么大道理了我把自己最近这段时间的真实状态、手上在推进的事、踩过的坑以及观察到的几个值得花时间的方向摊开来跟各位聊聊。如果你也正好处在“想看看别人在干嘛”的阶段那这篇文章或许能给你一些参考坐标——不是为了比较而是为了让你知道世界很大跑道很多每个人都有自己的节奏。1. 手头这两个“主食”项目一荤一素先交代一下背景我目前是自由职业状态主要接一些中小型团队的技术外包和产品顾问的活儿。所谓“自由”其实并不自由项目排期比坐班的时候还要满但好在时间可以自己支配能把精力投在真正感兴趣的事情上。这段时间我手上主要有两个项目在并行推进一个做得有点痛苦一个跑得还挺顺。1.1 从“鸡肋”到想扔掉的智能家居控制面板项目第一个项目是一个智能家居场景的控制面板应用给某个做全屋智能的小品牌做的。说起来不算复杂本质就是一个能跑在平板上、用来控制灯光、窗帘、空调、窗帘电机的中控界面但真正做起来才发现这里面的坑远比想象中多。首先是设备协议的问题。客户那边的设备不是走的统一标准协议而是各家混用有走MQTT的有走HTTP轮询的还有几个老设备用的是某品牌的私有UDP协议。这就意味着我在接入层要写好几套适配器而且这些适配器之间的行为还不太一致。比如某些设备的状态上报是推的某些是需要定时去拉的某些设备离线了不会主动通知你只能靠超时来判断。这块的逻辑我七改八改整整花了两周多才让状态同步基本稳定。然后是前端渲染的实时性问题。控制面板上要显示各个房间的温度、湿度、光照度这些数据是实时刷新的。最开始我用的是传统的setInterval轮询刷新每两秒拉一次接口结果在平板这种低功耗设备上发热明显而且页面一复杂就开始掉帧。后来换成了WebSocket长连接推送设备端那边又嫌并发连接数太多最后折中成“短轮询服务端聚合缓存”的方案总算把刷新频率和服务器压力平衡住了。这个项目做了一半说实话我内心一度想直接放弃。不是技术难度大而是需求边界一直晃。客户今天说“这里加一个场景模式”明天说“这个动画能不能换成另一种”后天又改回原来的方案。经历了三轮需求返工之后我终于学乖了任何改动都必须走文档记录邮件确认口头上的“我觉得”一律不算数。这算是我这个项目里收获最大的一条教训。1.2 给朋友帮忙的社区团购小程序反而跑得最快第二个项目挺有意思是给一个朋友做的社区团购小程序。他不是做技术的在小区边上开了一家水果店之前一直靠微信群接龙统计订单每天光核对订单就要花掉两个小时所以想做一个小程序解决这个问题。这个项目技术含量不算高后台就是一个简单的商品管理订单管理前端就是商品列表、下单、支付、核销这几件事。但为什么我说它“跑得最顺”因为需求极其明确就是解决一个具体问题把微信群接龙变成线上化操作。朋友每天最烦的就是客户发“老板来两斤车厘子”他得手动记在笔记本上第二天再一个个核对。做了这个小程序之后客户自己下单他后台看汇总直接照着单子备货就行了。这个项目让我意识到一件事很多时候我们做技术的人容易陷入“技术本位”的思维觉得一定得用多牛X的架构、多新的框架才能体现水平。但实际上真正能帮人解决问题的工具哪怕只是简单的CRUD只要流程顺、体验稳、维护省心就是好产品。这个团购小程序我用的是Go写后端Vue写管理端小程序端用的原生语法部署在一台2核4G的轻量服务器上一个月成本几十块钱跑了两三个月了稳如老狗。2. 最近真正花时间研究的两类能落地的技术除了手头的项目我最近还在主动研究一些新的东西。现在技术圈的热点更新速度实在太快今天AI Agent明天边缘计算后天又是WebGPU要是什么都追精力和时间都会被撕碎。我现在的策略是只研究那些能在三个月内落地到实际项目里的东西。按照这个标准我筛出了两个方向最近确实在往深了挖。2.1 长连接方案的重新选型WebSocket之外的另一种思路因为我做的项目里实时通信的场景越来越多我花了些时间把“长连接”这件事重新梳理了一遍。以前一提到实时通信我下意识就是WebSocket但最近在做一个数据大屏项目的时候发现单纯的“服务端往客户端推数据”这种场景用SSEServer-Sent Events其实比WebSocket更合适。原因是SSE足够轻。它建立在一根普通的HTTP连接之上不需要像WebSocket那样进行一次独立的握手协议对现有的负载均衡、代理配置更友好。而且SSE自带自动重连机制断线了浏览器会自己恢复不需要前端写一堆重连逻辑。对于“温度数据每秒推一次”“订单状态变化时通知”这类单向推送场景SSE的代码量比WebSocket少一大截调试也简单。当然如果要做双向通信比如在线聊天、多人协作编辑这种需要客户端也持续发消息的场景那还是得用WebSocket。我在这块做了一个小小的性能测试单台2核4G的服务器上用SSE维持5000个并发长连接CPU占用率大概15%左右内存占用不到300M这个结果远比我预想的要好。如果你手头的项目也是“重推送、轻上行”的场景真的可以考虑试试SSE别再动不动就上WebSocket了。2.2 别再折腾新框架了把这块“旧地基”打牢更值第二个我花时间深耕的方向挺出乎我自己意料的——是Go语言的pprof性能分析和数据库索引优化。听起来很“基础”、很“不性感”对吧但我最近发现很多项目的性能问题其实都不是框架不够快而是我们根本没搞清楚瓶颈在哪。举个例子上个月帮一个电商客户排查接口超时的问题。接口本身逻辑很简单就是根据用户ID查询订单列表但每次请求都要2秒多。我第一反应是SQL没用上索引结果EXPLAIN一看明明走了索引。后来用pprof抓CPU火焰图才发现耗时的大头竟然在JSON序列化上——订单数据结构里套了三层嵌套对象每次序列化都会触发大量的反射调用。最后把数据结构压平、改成手动序列化之后接口耗时直接从2.1秒降到了300毫秒。这件事给我的触动挺大。我们总在追逐“更快的框架”“更新的语法”但真正让应用变慢的往往是那些不起眼的基础细节数据结构和序列化方式是否合理、连接池有没有被正确复用、缓存策略是不是在靠直觉设置。把这一层地基打扎实才是性价比最高的投入。最近我甚至开始在周末翻起《数据库索引设计与优化》这种老书了每一章读完都能在自己项目里找到相应印证。3. 踩过的坑三个印象最深的排错术既然是分享近况避不开的就是踩坑。这段时间这几个问题在排查过程中几乎快把我逼疯但事后回头看每条教训价值千金。3.1 偶发503错误的完整排查链路事情是这样的一个部署在K8s集群里的服务每天下午两三点左右会偶发几次503错误每次三五秒钟就自己恢复了不仔细看监控根本发现不了。但客户的业务对可用性要求高容不得这种“癫痫式”抖动于是我开始排查。第一反应是看网关日志发现503是从Nginx Ingress返回的后端Pod的日志里却在同一时间段没有对应的请求记录。这说明请求压根没到达后端服务是在网关层就被拦下了。那问题大概率出在上游超时配置或者健康检查上。继续看Ingress配置没发现什么异常。然后我开始怀疑是不是下午这个时间段流量高峰导致Pod被杀掉重建了。查了Pod的事件确实有OOMKilled的记录——内存Limit设置得太紧加上JVM的堆外内存一到访问量稍微上来一点就触发OOM。重启Pod之后因为就绪探针的initialDelaySeconds设得太短Pod还没完全起来就被标记为就绪流量打过去自然就503了。链路查完根因其实是两个问题叠加一个是内存Limit配置不合理另一个是就绪探针参数太激进。两个问题单独看都不会出大事故但凑在一起就把服务抖成了“抽风模式”。修复方案也很简单粗暴把内存Limit按照压测结果上调30%就绪探针的时间参数放宽到60秒之后观察了一周503再没出现。3.2 依赖升级的教训“最新版”不等于“最好版”第二个坑是关于依赖升级的我相信很多人都有类似经历。一个内部管理系统的前端项目原本用的Vue 2.6我接手之后觉得版本太老想升级到Vue 3。理论上这活儿不难用官方提供的迁移构建工具跑一遍把生命周期钩子和API调用方式改一改就行。结果一跑起来直接傻眼。项目里一个用了很久的表格组件库在Vue 3下直接不兼容但项目的表格交互特别复杂——有合并单元格、有自定义筛选器、有行内编辑——换库的话整个交互层都要重写。当时我大概算了算重写这个表格组件的工作量比把项目里所有其他代码升级的工作量加起来还要大。最后我只能选择“部分升级”的方案核心页面保持Vue 2.6不动新开发的模块用Vue 3并用微前端的方式嵌进去两个版本共存。这个方案确实不太优雅但业务不能停在这等我把表格重写完毕。这个坑给我最大的教训是升级依赖之前先把这个项目里所有第三方库的兼容性摸清楚尤其是那种长年不更新但又被重度使用的库很可能就是大坑本身。3.3 文档和代码“各说各话”接口联调的灾难第三个坑跟技术关系不大但造成的影响真不小。一个前后端分离的项目后端同学写接口文档用的是Swagger但他有两次改了字段名之后没同步更新文档导致前端按文档联调了半天一对接全是undefined。而且那个接口的返回值结构比较复杂是嵌套了三层的JSON字段改动藏得很深前端根本没法一眼发现。最后是在联调环境里加了字段校验中间件每次返回数据自动比对文档定义的schema不一致就直接在测试环境抛异常才把这个隐患彻底兜住。这事让我养成了一个习惯只要是接口联调阶段必须给测试环境的接口加“Schema校验”这一层。不要指望每个人都能自觉更新文档机器强制校验才是真正的保障。4. 怎么安排精力几个土办法自由职业看起来时间自由实际上最不自由的就是精力管理。没有外力约束全靠自觉和一套适合自己的工作规矩。跟各位分享几个我最近在用的方法不一定科学但确实缓解了我的焦虑和疲惫。4.1 物理隔离工作区一个时段只开一个项目我以前有个毛病电脑桌面上能同时摊着四五个项目的窗口一会儿写两行这个一会儿又切到那个去改个bug。结果是每个项目都处于“半拉子”状态大脑不停切换上下文一天下来感觉忙了12个小时但每个项目的进度条都没怎么动。现在我的做法是物理隔离一个时段只开一个项目这个时段内绝不打开另一个项目的终端和IDE。我会用块计时器一个番茄钟25分钟中间休息5分钟每四个番茄钟休息长一点。听起来很死板但真的有效——至少我老婆说我现在每天晚饭后不会像以前那样“魂还在电脑里”了。4.2 把“想”和“做”分开焦虑感瞬间减半另一个方法是把“想”和“做”分开。人在焦虑的时候往往会陷入一种“反复在脑子里盘算但就是不动手”的状态。我发现最好的解药是拿出一张纸把脑子里那些盘旋的想法一条条写下来不做任何判断不做任何决策只是“倒出来”。写完之后再逐条标注哪些是现在就能动手做的哪些是需要等待别人反馈的哪些其实是根本不重要的。你会发现真正需要你现在操心的事情往往只有两三件剩下的都是大脑自己在那里放烟花制造噪音。这个习惯是跟我一个做产品经理的朋友学的他现在已经是某大厂的业务线负责人了他说他每天到公司的第一件事就是做这个“脑内垃圾倾倒”风雨无阻。4.3 给自己留点“无聊时间”灵感反而冒出来了最后这半年我重新开始刻意给自己留一些“无聊时间”。不刷手机、不开电脑、不看视频就是纯粹地发呆、散步或者做点体力活。一开始确实浑身不自在总想摸出手机来看一眼但坚持了一段时间之后我发现很多白天卡住的技术问题居然会在这种放空状态下意外冒出思路。其实原理也不难理解——大脑在“默认模式网络”下会重新整理记忆碎片把白天那些思维盲区里的信息重新连接起来。有些事情不是靠死磕就能解决的放松之后让潜意识接管一会儿反而更容易看到答案。这个状态我觉得挺像给自己的大脑做一次碎片整理成本为零效果却很惊艳。那你们呢文章写到这里不知不觉就变成了自己近期的一次“述职报告”。回到开头那个问题——你最近在做什么是还在原来的轨道上深耕某一项技术、某一个业务还是已经切换了完全不同的赛道是在为“眼下的事”焦头烂额还是开始认真琢磨“下一件事”该往哪儿走了我个人最近体会最深的一点是不管在做什么能让自己越做越精神的事情大概率就是值得持续投入的事情反之如果一件事情让你每天早上醒来都像上刑一样抗拒那就算钱给得再合适也得认真考虑是不是到了该调整方向的时候。技术也好、行业也好潮水一直在动我们每个人其实都是在边看边学、边走边调整。欢迎在评论区随意聊聊——你不必写得很正式就当是跟朋友吃饭的时候随口说一句“我最近在忙一个啥啥啥”就好。我会挑一些有意思的方向在后面整理成专题继续跟大家细聊。