我对技术探索与实践的看法：一个奶爸程序员的深夜碎碎念
凌晨1点17分，两个娃终于睡了。老婆刚发来微信：“你今晚还学不学？不学我就关灯了。”我赶紧回复：“马上！就看最后一章！”——合上《Designing Data-Intensive Applications》，顺手打开终端跑了个 git pull，突然意识到，这大概就是我这个深圳腾讯系公司的普通后端工程师、两个娃的奶爸程序员，最真实的日常。
我不是那种凌晨三点还在刷 LeetCode 的卷王，也不是 GitHub 万星项目的作者。我只是个被 deadline 追着跑、被产品经理“小需求”搞得血压飙升、偶尔还要帮测试复现“在我本地跑得好好的” bug 的普通人。但正是在这种夹缝中，我对“技术探索与实践”这件事，有了些不太一样的想法。
从“被迫学习”到“主动挖坑”
去年双11前两周，我们组接到一个紧急需求：要给一个高并发交易系统加一层“可追溯”的能力。产品经理原话是：“用户要能查到每一笔钱是怎么来的、去哪了，最好还能防篡改。”
我第一反应是：“这不就是……区块链？”
但转念一想：别闹，咱又不是要做币圈项目。
可领导很认真：“不是让你上链，是要借鉴它的不可篡改和可追溯思想。你可以看看有没有轻量级方案。”
于是，那个周末，我在娃睡午觉的两小时里，翻出了之前收藏但一直没动的《Mastering Blockchain》。书很厚，但我只啃了前三章——因为后面全是智能合约和共识算法，跟我们业务关系不大。真正救我的，是书中提到的 Merkle Tree（默克尔树） 和 append-only log（仅追加日志） 模型。
我们最终没用任何区块链框架，而是基于 Kafka + 自定义 Merkle 根校验，实现了一个轻量级的“操作流水账本”。每笔交易生成一个哈希指纹，按时间顺序拼接成树，定期将根哈希存入数据库。这样即使有人想篡改中间某条记录，也会导致根哈希对不上——简单、高效、可审计。
上线那天，运维同事调侃：“你们这是搞了个‘伪区块链’啊？”
我苦笑：“伪不伪不重要，重要的是双11没挂。”
技术探索 ≠ 追新，而是解决问题的“工具箱思维”
很多人一提“技术探索”，立马想到 Web3、AI Agent、Rust 重写一切……但作为一个每天被娃尿布和 Jira 工单轮番轰炸的人，我深知：探索的意义，不在于用了多酷的技术，而在于是否用对了工具。
举个例子：上周五晚上9点，线上突然报警——某个服务的响应延迟从 50ms 飙到 2s。我一边哄老二睡觉，一边远程排查。日志里全是：
[WARN] DB connection pool exhausted, waiting...
乍一看是数据库连接池打满。但奇怪的是，QPS 并没有突增。经过一番 tcpdump + pprof，发现是某个新上的“异步回调”逻辑，在失败时无限重试，且每次重试都开了新事务，却不释放连接。
这时候，我脑子里闪过的不是“要不要换 Go 1.22”或者“上 Service Mesh”，而是翻出《Database Internals》里关于连接池管理的那一章。最后解决方案极其朴素：加个指数退避 + 最大重试次数限制，再配个熔断开关。
你看，真正的技术探索，往往是“在正确的时间，想起正确的书里的一段话”。
为什么我坚持读书，哪怕每天只有20分钟？
在深圳这种地方，技术更新快得像地铁11号线——你刚学会 React，Vue 3 已经普及；你刚搞懂 Kafka，Pulsar 又冒出来了。很多人靠刷 Medium、掘金、InfoQ 跟进趋势，但我越来越觉得：碎片化信息治标不治本。
比如最近大家都在吹“区块链+AI”，听起来很玄。但如果你读过《Blockchain Basics》里对“状态机复制”的解释，再结合《Hands-On Machine Learning》里模型版本管理的痛点，就能明白：区块链在这里可能只是个“可信的模型元数据存储”，根本不需要完整链。
我现在的读书策略很“奶爸式”：
- 通勤地铁上：听技术播客（推荐《Software Engineering Daily》）
- 午休20分钟：精读1节经典书籍（比如《Clean Code》或《Patterns of Enterprise Application Architecture》）
- 娃睡后：动手写 demo 或整理笔记（用 Obsidian 做知识图谱）
书不是用来“读完”的，是用来“调用”的。 就像我在做微服务拆分时，突然想起《Building Microservices》里说的“bounded context mapping”，立刻避免了一次错误的领域划分。
区块链？别神化，也别妖魔化
说到区块链，作为腾讯系公司的程序员，我其实接触不少。腾讯有 TBaaS（TrustSQL），内部也有不少基于区块链的存证、溯源项目。但实话实说：90% 的场景根本不需要链。
我见过最离谱的需求是：“我们要用区块链做用户登录！”
我反问：“你是担心 MySQL 被黑，还是觉得 SHA256 不够安全？”
对方支支吾吾：“领导说要上链……”
后来我画了张对比表，说服了产品：
| 方案 | 开发成本 | 性能 (TPS) | 运维复杂度 | 是否真需防篡改 |
|---|---|---|---|---|
| 传统数据库 + 审计日志 | 低 | 10k+ | 低 | 否（内网可信） |
| 私有链（Hyperledger） | 高 | ~500 | 高 | 否 |
| 公链（以太坊） | 极高 | ~15 | 极高 | 绝对不需要 |
结果？我们用 PostgreSQL 的 pg_audit 扩展 + 定期快照校验，搞定。省下两个月人力，多陪娃去了两次海边。
但区块链并非无用。在跨组织协作、多方不可信环境（比如供应链金融、司法存证），它的价值就凸显了。关键是要区分“信任问题”和“性能/扩展性问题”。如果你的问题本质是“怎么让A公司相信B公司的数据没造假”，那链可能是解；如果只是“系统慢”，请先看看你的索引。
实践：从小处着手，构建“可验证”的工程习惯
技术探索不能只停留在“知道”，必须落到“做到”。这几年我给自己定了几个小规矩：
每个新技术，必须写一个最小可运行 Demo（MRD）
比如学 Solidity，我不直接写 DeFi，而是先实现一个“带时间锁的保险箱合约”，然后用 Hardhat 测试覆盖所有边界条件。代码提交必须附带“为什么”
我们团队现在要求 PR 描述里写清楚：这个改动解决了什么问题？有没有替代方案？参考了哪些资料？（经常引用书页码，比如：“参考《DDD》p.128 的聚合根设计”）定期做“技术债务 Review”
每月最后一个周五下午，我和同事会花1小时，列出三个最想重构的模块，并评估：是架构问题？还是当初图快写的烂代码？然后分配“技术债积分”，用 OKR 推动偿还。
上周我们就干掉了一个“祖传”的 XML 配置解析器——它居然还在用 DOM4J，内存溢出三次了。换成 Jackson 的 XML 模块，代码行数减少 60%，性能提升 3 倍。那一刻，比娃第一次叫“爸爸”还爽（别告诉老婆我说这话）。
结语：在现实的泥泞中，保持仰望星空的能力
有人说，35岁以后就该 focus on management，别折腾技术了。但作为一个天天被娃折腾、被需求折磨的奶爸，我反而觉得：技术探索是我对抗平庸的方式。
它让我在修玩具车时想到“状态机设计”，在排队打疫苗时思考“分布式一致性”，甚至在老婆抱怨“你又在看电脑”时，能笑着说：“我在研究怎么用零知识证明向你证明我没偷偷买游戏机。”
技术不是炫技，不是简历镀金，而是一种思维方式——如何抽象问题、如何权衡取舍、如何在约束中寻找最优解。而书籍，就是前人踩坑后留给我们的地图；区块链，也只是工具箱里的一把特殊扳手。
所以，如果你也和我一样，白天写业务代码，晚上哄娃睡觉，周末还要被叫去 support 线上事故——别焦虑。
你不需要成为全栈大神，只需要在下一个需求来临时，比昨天的自己多一个解法。
毕竟，真正的技术前瞻性，不是预测未来，而是在未来到来时，你已经准备好了。
（完）
P.S. 写完这篇文章时，已经是凌晨2:30。老婆已经睡了，但我在 terminal 里敲下
git push origin main的那一刻，心里莫名踏实。明天早上6点又要起床冲奶粉，但至少今晚，我为自己的“工具箱”又添了一颗螺丝钉。
评论 0