技术探索不是刷题，是为产品扛资源的活

上周五晚上十一点，我刚把婚庆公司发来的第三版请柬设计图改完配色，钉钉就弹出一条消息：“明天上线前压测，你那块缓存逻辑再过一遍。” 我一边在心里默念“别炸别炸”，一边点开 VS Code——这大概就是杭州备婚程序媛的日常：左手捧花右手日志，白天写代码晚上挑婚纱。

我是阿里某中台团队的后端开发，坐标西溪园区，早起型选手，8点准时坐到工位上泡枸杞茶（别笑，我们组95后都开始养生了）。最近几个月，一边忙着双11大促的架构加固，一边和未婚夫敲定婚礼细节，连面试邀约都懒得点了。但今天想写点东西，不是为了跳槽，也不是为了卷，而是被最近几次技术讨论逼出来的思考——我们到底为什么做技术探索？

很多人以为，搞技术就是刷 LeetCode、背八股文、追新框架。可现实是，去年双11压测时，一个缓存穿透差点让整个订单链路雪崩，而当时我脑子里闪过的根本不是“Redis 缓存穿透怎么解决”，而是“如果挂了，产品那边的 GMV 目标怎么办”。

从一道“简单”的面试题说起

前几天帮内推的朋友模拟面试，问了个经典题：“如何设计一个高并发的秒杀系统？”
他张口就来：“用 Redis 做库存预减，MQ 削峰，本地缓存防击穿……”
听起来很标准，但我打断了他：“如果资源有限，只能选两个方案，你先保哪个？”

他愣住了。

这其实不是考技术，是考权衡。在真实业务中，资源永远是有限的——服务器预算、人力排期、运维支持、甚至你自己的精力。我们团队去年做会员积分兑换，初期也想上全套高可用架构，但产品说：“先跑起来，用户量不到十万别谈 QPS。” 于是我们用最朴素的数据库行锁 + 重试机制撑了三个月，等数据跑出来，才针对性加缓存、拆服务。

技术探索的起点，从来不是“这个技术牛不牛”，而是“这个产品值不值得我砸资源”。

产品驱动的技术决策，才是真架构

我在阿里待了四年，最大的体会是：好架构不是设计出来的，是被产品需求“逼”出来的。

举个例子。我们有个内部工具，早期只是个脚本，产品经理临时要加个“实时导出报表”功能。我一开始直接 SELECT * FROM huge_table，结果 DBA 找上门：“你这查询把主库 IO 打满了！”
当时 deadline 就在三天后，不可能重构。怎么办？

• 方案 A：加只读副本 → 要申请机器、走审批、等部署，至少一周
• 方案 B：改成分页 + 限流 → 用户体验差，导出要等半小时
• 方案 C：用 Elasticsearch 做异步索引 → 需要额外维护一套数据同步

最后我选了 D：把大表按时间分片，只查最近 30 天，并加了个“历史数据需申请”的提示。产品居然欣然接受——因为 95% 的用户只关心近期数据。

你看，这不是炫技，这是在资源约束下，用最小成本满足核心需求。技术人常犯的错，就是沉迷于“完美方案”，却忘了产品要的是“能用且快”。

资源不是无限的，但可以聪明地分配

说到资源，杭州互联网圈有个潜规则：谁会“省资源”，谁就是好工程师。

阿里内部有资源成本核算，每个服务的 CPU、内存、存储都要计入团队账单。去年我们优化一个老服务，发现它每天凌晨跑批处理，占用了 4C8G 的实例整整 6 小时。我提了个方案：用 Serverless 函数替代，按执行时间计费。结果一算，月成本从 ￥1200 降到 ￥80。

但这不是技术多高明，而是意识到资源是钱，而钱是产品的命脉。很多新人觉得“公司不差这点钱”，但当你经历过预算砍半、项目叫停，就知道每一分资源都要精打细算。

下面是我们团队常用的资源优化手段对比：

优化手段	适用场景	成本降幅	实施难度	风险
数据分片	大表查询、高写入	30%-50%	中	分片逻辑复杂
缓存分级	热点数据、重复计算	40%-70%	低	缓存一致性
Serverless	异步任务、低频服务	60%+	中	冷启动、调试困难
读写分离	读多写少	20%-40%	高	主从延迟
静态化	内容展示、配置类数据	80%+	低	更新延迟

注意，没有“最好”的方案，只有“最合适”的。比如 Serverless 虽然省钱，但我们的核心交易链路绝不敢用——冷启动几百毫秒，用户早就跑了。

技术探索的正确姿势：从问题出发，而非从工具出发

我见过太多人学新技术是因为“听说很火”，结果学完发现用不上。我自己也踩过坑。前年 Kubernetes 火的时候，我花了两周搭了个集群，结果我们服务还在用 EDAS，根本没机会上 K8s。

后来我改了策略：先找问题，再找工具。

比如最近我们在做多租户 SaaS 产品，遇到隔离问题。传统方案是数据库分库，但运维成本高。我调研了 Postgres 的 Row Level Security（RLS），发现它能在单表内实现租户隔离，省了 60% 的 DB 实例。这才去深入学 RLS 的权限模型和性能影响。

这种探索才有价值——它直接服务于产品目标，且能落地到资源节省。

反观那些“为学而学”的技术，往往变成简历上的装饰品。面试官问“你用过 Kafka 吗？”，你说“搭过 demo”，他心里 already know：这人没真用过。

别被“八股文”绑架，真实世界比面试题复杂一万倍

说到面试题，我必须吐槽一句：现在的面试题越来越像脑筋急转弯，离实际工作越来越远。

比如“如何设计 Twitter？”——请问你 Twitter 日活多少？用户分布在哪？合规要求有哪些？这些不说，光画个架构图有什么用？
我在网易实习时，面试官问：“如果 Redis 挂了怎么办？” 我答：“看 SLA，如果是非核心功能，直接降级；如果是核心，走多级缓存+本地缓存兜底。” 他点头说：“这才是生产环境思维。”

真实世界里，技术决策=风险评估+成本计算+团队能力。你不能指望一个 3 人小团队搞出 Netflix 级别的容灾。

上周我们线上出了个诡异 Bug：用户支付成功但订单状态没更新。查了半天，发现是消息队列消费超时，而重试机制没覆盖幂等。这时候，没人关心你懂不懂 CAP 理论，只关心“多久能修好”和“会不会丢数据”。

所以，我对技术探索的看法很简单：别为了面试而学，要为了扛住明天的线上流量而学。

写在最后：技术人的浪漫，是让产品活得更久

备婚这段时间，我常和未婚夫聊职业规划。他说：“你整天改代码，不累吗？”
我说：“累，但看到用户用我们做的功能解决问题，就觉得值。”

技术探索对我而言，不是刷题升级，而是在有限的资源下，为产品构建一道防线。这道防线可能不够酷，但足够稳；可能不前沿，但能扛住双11的洪峰。

所以，下次当你面对一个技术选型，别急着 Google 最佳实践。先问自己：

• 这个功能对产品有多重要？
• 我们有多少资源可以投入？
• 如果失败，最大损失是什么？

答案出来了，技术方案自然就清晰了。

毕竟，在杭州这座卷到飞起的城市，能活下来的产品，才是好产品。而我们程序员，就是那个默默在背后给产品“续命”的人。

（写完这篇，我得去回婚庆公司的消息了——他们又改了主舞台的灯光方案。希望这次别再让我凌晨三点爬起来改代码了。）