技术探索与实践的一些思考
上周五晚上十点半，我合上笔记本，揉了揉发酸的眼睛。窗外的上海夜色正浓，公司楼下还停着几辆滴滴司机师傅的车——他们可能刚送完最后一单，准备收工。而我，刚修完一个线上偶现的“幽灵” Bug，心里却比跑完一趟跨江订单还累。
我是滴滴后端团队的一名工程师，在司机端业务线摸爬滚打了快四年。说白了，就是管司机师傅们用的那个 App 背后的服务逻辑：接单、派单、计费、状态同步……听起来平平无奇，但每一行代码背后，都连着真金白银和用户的体验。去年双11期间，我们系统 QPS 瞬间翻了三倍，那几天我做梦都在看 Grafana 面板。
今天想聊聊最近半年在技术探索上踩过的一些坑，也顺便整理下自己的思路。不是什么高深理论，就是普通码农在日常搬砖中，如何不被新名词吓死、又不至于原地躺平的一点心得。
产品要啥？先别急着写代码
事情得从三个月前说起。产品经理（以下简称 PM）小王突然在站会上抛出一个需求：“我们要做一个‘绿色出行激励计划’，司机完成特定任务就能领碳积分，还能兑换实物。” 听起来很酷，对吧？但当我追问细节：“积分怎么算？链上存还是数据库存？前端展示逻辑是？” 他挠头笑：“技术细节你们定，反正 UI 原型下周一给。”
好家伙，又是熟悉的配方。不过这次不同的是，PM 特意提了一句：“老板看了某篇区块链白皮书，觉得这个方向很有‘未来感’。”
我当场就警觉了——区块链？我们一个日活百万级的司机端系统，真要上链？先不说 TPS，光是 Gas 费就得烧穿预算。但直接 say no 又不行，毕竟“战略方向”。
于是我和前端老李、架构师老张开了个三人小会。老李第一反应是：“前端展示积分页面没问题，但你们后端要是搞个延迟 5 秒的接口，用户点一下等半天，我可不背锅。” 我深以为然。用户体验不能为技术噱头买单。
我们最终决定：核心业务逻辑仍走传统数据库，只把“积分发放记录”做一次哈希上链，作为不可篡改的审计凭证。既满足了“区块链”这个关键词，又没动主干流程。上线后效果不错，司机师傅们根本感知不到背后有没有链，但他们能秒开页面、即时看到积分到账——这才是产品该有的样子。
教训：技术再炫，也得服务于产品目标。别为了用新技术而用，尤其是当 PM 自己都说不清需求时。
前端不是“切图仔”，合作才能少返工
说到前端，以前我确实有点“后端傲慢”——总觉得他们就是调接口、写 CSS，能有多难？直到去年重构司机端的“行程详情页”，才彻底被打脸。
那个页面要实时显示路线、乘客位置、预计到达时间、异常预警……数据源来自至少 5 个微服务。我一开始给的接口是粗粒度的：GET /trip/{tripId}，返回一堆嵌套 JSON。结果老李直接在群里@我：“兄弟，你这字段命名像乱码，而且有些字段我根本用不上，每次请求都多传 20KB，司机在郊区信号差的时候加载慢得想卸载 App。”
我这才意识到，前后端的边界不是接口文档，而是用户体验。后来我们改用 GraphQL，让前端按需查询；字段命名也统一了规范（比如 passenger_pickup_location → pickupLoc）。虽然后端多写了点 resolver 逻辑，但整体包体积小了 30%，页面首屏快了近 1 秒。
现在每次 PR，我都会主动问老李：“这个字段你前端需要吗？要不要拆成两个接口？” —— 毕竟，好的 API 设计，是聊出来的，不是拍脑袋写的。
读书有用吗？看你怎么读
很多人说程序员不用读书，看文档、刷 GitHub 就够了。这话对一半。文档教你“怎么做”，但书能告诉你“为什么这么做”。
去年我被安排优化一个调度算法模块，性能瓶颈卡在 Redis 的 ZSET 排序上。当时网上各种“高性能 Redis 实战”教程满天飞，但我越看越迷糊。直到翻开《Redis 设计与实现》第 8 章，才真正理解 skiplist 的底层结构——原来 ZRANGE 的时间复杂度不是 O(1)，而是 O(logN + M)！
豁然开朗之后，我把热数据分片+本地缓存+异步更新三板斧一套，QPS 直接从 3k 干到 12k。那一刻，我对着书傻笑了五分钟——有些弯路，书早就替你踩过了。
当然，也不是所有书都值得啃。我现在选书就三个标准：
- 作者有真实项目经验（别是纯理论派）
- 出版时间在近五年内（技术迭代太快）
- 有配套代码或案例（最好能跑起来）
最近在读《Designing Data-Intensive Applications》，虽然厚得能防身，但每章都像和一位资深架构师对谈，值了。
关于“新技术焦虑”：别慌，先跑通再说
说实话，这几年技术圈卷得厉害。AI、Web3、Serverless、AIGC……每天都有新词轰炸。我一度焦虑到半夜爬起来看 Medium 博客，生怕被时代抛弃。
但带我的导师说过一句话让我记到现在：“技术栈不重要，解决问题的能力才重要。” 他在滴滴十年，从 PHP 写到 Go 再到 Rust，但核心能力始终是：拆解问题、权衡取舍、快速验证。
比如上个月，团队要接入一个新的风控服务。对方推荐用 gRPC，但我们现有体系全是 HTTP/JSON。有人提议全量改造，我则做了个 PoC：用 Envoy 做协议转换，后端不动，只改网关层。三天搞定，性能损耗不到 5%。领导看完直接拍板：“就这个方案，别折腾了。”
你看，有时候“不够新”的方案，反而是最稳的。
最后一点碎碎念
技术探索不是赶时髦，而是为了更好地交付价值。在滴滴这四年，我越来越觉得：代码质量 > 架构高度，可维护性 > 技术新颖度。一个能快速定位、易于扩展的系统，远比一个用了十个新框架却没人敢动的“艺术品”更珍贵。
当然，该学还得学。下周我就报名了公司内部的区块链 workshop——不是为了立刻用上，而是搞懂它到底适合解决什么问题。万一哪天 PM 又提“元宇宙司机社区”呢？（手动狗头）
写这篇博客的时候，已经是凌晨一点。楼下还有滴滴在跑。希望我的代码，能让某个司机师傅少等一单，多赚十块。
共勉。
附：技术选型对比（以碳积分场景为例）
| 方案 | 存储方式 | 一致性 | 性能 | 开发成本 | 是否采用 |
|---|---|---|---|---|---|
| 全链上存储 | Ethereum | 强一致 | 低（~15 TPS） | 高 | ❌ |
| 仅哈希上链 | DB + ETH | 最终一致 | 高 | 中 | ✅ |
| 纯中心化 | MySQL | 强一致 | 高 | 低 | ⚠️（不满足审计需求） |
小技巧：如何快速验证一个新技术？
# 1. 本地起个 demo（别碰生产！）
docker run -it --rm ethereum/client-go
# 2. 写个最小可行脚本
python3 poc_blockchain_hash.py
# 3. 测关键指标：延迟、吞吐、资源占用
hey -z 30s -c 50 http://localhost:8080/api/v1/record
# 4. 找前端同事一起看 UX 影响
记住：跑通 > 完美，验证 > 空想。
评论 0