技术探索不是炫技，是为了解决真问题
去年七月，我裸辞了。在大厂卷了五年，从“优化一下首页加载速度”到“双11零点不能崩”，再到“这个需求很简单，明天上线”，终于有点喘不过气。Gap这半年，没躺平——白天研究开源项目源码，晚上给远程兼职项目调性能，偶尔撸猫、煮咖啡，顺便把区块链相关的几个核心库翻了个底朝天。
很多人以为技术人探索新技术，是为了写简历上多几个 buzzword。但对我来说，真正驱动我去折腾的，从来不是“会什么”，而是“能不能解决眼前这个破问题”。
从一次线上事故说起
去年双11前两周，我们一个电商后台的运营系统突然卡成 PPT。运营同学反馈：“改个活动配置要等三十秒，页面转圈转得我怀疑人生。”
运维拉日志一看，数据库 CPU 直接飙到 98%，慢查询堆积如山。
问题是：这系统根本没动过啊！代码还是三个月前的老样子。
我接手排查，发现罪魁祸首是一个看似无害的“运营数据统计接口”。它每次请求都会全表扫描用户行为日志，再 join 十几张表，只为生成一个运营看板上的小图表。而运营同学为了对齐 KPI，每五分钟就手动刷新一次——人肉压测，效果拔群。
当时真的想砸电脑。但冷静下来一想：这不就是典型的“技术债 + 运营流程脱节”吗？技术团队以为运营只看日报，结果人家实时盯盘；运营以为点一下“刷新”天经地义，不知道背后是全表扫描。
于是，我做了三件事：
- 缓存预计算：把高频查询的结果提前算好，存 Redis，TTL 5 分钟。
- 权限隔离：给运营后台加了“轻量模式”，默认只加载必要数据。
- 埋点监控：记录每个操作的耗时和触发频率，反向推动运营优化操作习惯。
上线后，DB 负载降了 70%，运营同学也学会了“别狂点刷新”。
这件事让我意识到：技术探索必须和业务场景深度耦合。脱离运营实际的“高性能架构”，不过是纸上谈兵。
区块链？别被 hype 带偏了
说到热门技术，不得不提区块链。裸辞那会儿，正好赶上某大厂高调宣布“All in Web3”，朋友圈全是“去中心化改变世界”的宣言。
我一开始也热血沸腾，拉了几个开源项目（比如 Ethereum 的 Geth、Hyperledger Fabric）跑起来，读源码、搭节点、写智能合约。但越深入越清醒：99% 的业务根本用不到区块链。
举个例子：有个朋友公司想用区块链做“商品溯源”。听起来很酷，对吧？但仔细一问，他们的供应链数据全是内部 ERP 系统生成的，根本没有多方不可信节点参与。这种场景，上个 PostgreSQL 加个审计字段不香吗？非要用区块链，结果维护成本翻倍，TPS 还不如 MySQL。
我在家远程接的一个项目倒是真用上了区块链——一个跨境支付结算平台。这里的关键需求是：多方机构互不信任，但需要共享交易状态，且不可篡改。这时候，区块链的价值才真正体现出来。
我们的做法很务实：
- 核心账本上链（用私有链，非公链）
- 非关键数据（如用户头像、日志）仍存在传统数据库
- 智能合约只处理状态变更逻辑，不做复杂计算
性能方面，通过批量提交 + 异步确认，把 TPS 从 15 提升到 200+。虽然远不如中心化系统，但满足了合规与信任的需求。
技术选型不是比谁更“新潮”，而是看谁更能精准匹配业务痛点。别让“区块链”变成你 PPT 上的装饰品。
性能优化：别只盯着代码
作为性能优化爱好者，我曾经沉迷于 micro-benchmark，一个 for 循环能优化出三种写法。但在大厂几年，最大的教训是：真正的性能瓶颈，往往不在算法，而在协作流程。
比如有一次，前端抱怨 API 太慢。我查了半天代码，发现后端其实 50ms 就返回了。问题出在哪？CDN 缓存策略配错了，静态资源每次都回源。而 CDN 配置是运维管的，前后端根本不知道这层依赖。
再比如，测试环境数据库是 SSD，生产却是机械盘，结果压测数据完全失真。上线当天直接雪崩。
这些坑让我养成一个习惯：优化前先画数据流图。从用户点击开始，一路追踪到 DB、缓存、第三方服务，甚至网络运营商。很多时候，问题出在你“以为没问题”的环节。
下面是我现在做性能分析的 checklist（简化版）：
| 层级 | 检查项 | 工具示例 |
|---|---|---|
| 客户端 | DNS 解析、TCP 建连、TLS 握手 | Chrome DevTools, WebPageTest |
| 网络 | CDN 命中率、BGP 路由 | Pingdom, Cloudflare Analytics |
| 服务端 | GC 频率、线程阻塞、连接池 | Arthas, Prometheus + Grafana |
| 数据库 | 慢查询、锁等待、索引缺失 | slow_log, pt-query-digest |
| 业务逻辑 | 是否重复计算？能否异步？ | 日志埋点、火焰图 |
记住：最快的代码，是根本不执行的代码。能缓存就缓存，能异步就异步，能删需求就删需求（bushi）。
开源项目：最好的老师
Gap 期间，我花了大量时间读开源项目源码。不是为了“显得厉害”，而是因为——真实世界的工程决策，教科书里没有。
比如看 Redis 的持久化机制，你会发现 RDB 和 AOF 不是二选一，而是组合使用；看 Kubernetes 的控制器模式，才真正理解“声明式 API”如何落地；甚至看一个简单的 CLI 工具（比如 Vite），也能学到如何优雅处理用户输入和错误提示。
更重要的是，开源社区逼你学会写给人看的代码。大厂内部项目往往“能跑就行”，注释稀烂，文档靠口口相传。但开源不行——没人愿意接手一团乱麻。
我现在写代码，会下意识问自己：“如果这段代码被扔到 GitHub，别人能看懂吗？” 这种思维，极大提升了我的工程素养。
最后一点真心话
技术探索的本质，不是追逐热点，而是持续提升解决问题的能力。无论是优化一个 SQL 查询，还是设计一个去中心化协议，核心都是：理解问题、权衡方案、交付价值。
运营要效率，我们就给缓存；业务要可信，我们就上链；系统要快，我们就砍掉冗余逻辑。技术是手段，不是目的。
裸辞这半年，我反而更清楚自己想要什么了：不做工具人，也不做技术宅。做一个能用技术撬动业务价值的工程师。
对了，上周五晚上，我又接到一个新需求：“能不能让页面加载再快 100ms？”
我笑了笑，回了一句：“行，但这次，咱们先对齐下运营的刷新频率？”
评论 0