那些年，我遇到的奇葩需求

写这篇文章的时候，我正坐在杭州城西一间咖啡馆里。窗外是阴雨绵绵的梅雨季，桌上摆着一杯美式和一本翻旧了的《Designing Data-Intensive Applications》。上个月刚从某大厂技术总监的位置上离职，准备自己搞点事情。说实话，做管理这几年，代码写得少了，但心里那股对“优雅系统”的执念反而越来越重。

今天不想聊架构图，也不想讲微服务拆分。就想唠点实在的——那些年我在后端开发路上踩过的坑、熬过的夜，以及……产品经理们提出来的让我想当场辞职的“创意”。

---

“用户删除账号后，所有数据必须保留72小时，但前端要显示‘账号已注销’”

这是我在阿里系某电商团队时的真实经历。时间点：2021年双11前两周。

需求背景听起来很合理：“为了防止用户误删，我们加个72小时冷静期。”
但具体实现要求是：用户点击“注销”，系统立刻返回“账号已注销”，前端页面变灰不可操作；可与此同时，数据库里的用户数据、订单记录、优惠券……一个都不能删，还得能随时恢复。

我第一反应是：“这不就是软删除（soft delete）吗？加个is_deleted字段，前端根据状态渲染不就完了？”
结果产品补了一句：“不行，用户看到‘已注销’，就得以为自己真的没了。如果他第二天反悔，我们要假装‘奇迹般地帮他找回账号’。”

好家伙，这不是技术问题，这是魔术表演。

更离谱的是，法务部还要求：在这72小时内，如果用户重新注册同手机号，必须提示‘该账号正在注销流程中，无法注册’。也就是说，手机号虽然逻辑上“可用”，但又不能被新用户占用。

于是我们搞出了一套“幽灵用户”机制：

• 用户触发注销 → 系统打标 status = 'ghost_pending'
• 前端根据此状态显示注销页
• 所有关联数据保留，但查询接口加过滤条件
• 新注册时校验手机号是否在“幽灵池”中
• 72小时后，定时任务真正物理删除或归档

那天晚上我和两个后端兄弟改到凌晨三点，测试用例写了50多条。最崩溃的是，有个边界 case：用户在第71小时59分钟重新登录，系统得自动取消注销流程，并把所有状态回滚——包括他之前领的那张“仅限注销用户可见”的安慰券。

上线那天，我盯着监控看了整整两小时，生怕半夜被 PagerDuty 叫醒。还好，双11平稳度过。后来产品请我们喝了杯奶茶，说：“你们后端真牛，连这种需求都能接住。”

我笑着点头，心里却在想：有些需求，不是技术做不到，而是它根本不该存在。

---

“能不能让数据库支持模糊搜索，像 Google 一样？”

这是在网易做内容平台时的故事。团队来了个新 PM，名校毕业，思维活跃，开口闭口“用户体验”、“心智模型”。

有一天站会上，他兴奋地说：“我们现在的内容搜索太弱了！用户搜‘杭州好吃的面’，结果只匹配标题里有这几个字的文章。能不能做到像 Google 那样，理解语义？比如文章里写‘片儿川超赞’，也能被搜到？”

我心想：你是不是对 Elasticsearch 有什么误解？

但他说完下一句，我直接愣住：“不过我们预算有限，不能上新中间件。最好就在现有 MySQL 上实现。”

全场沉默三秒。DBA 同事差点把咖啡喷出来。

MySQL 的全文索引？那玩意儿在中文场景下基本废了。而且我们的内容表已经上亿行，加 FULLTEXT 索引？光建索引就能把主库干趴。

我硬着头皮提议：“要不我们先做个关键词 tag 系统？编辑发布时手动打标签？”
PM 摇头：“用户不会打标签的，我们要的是‘无感智能’。”

最后怎么办的？我翻出了尘封已久的 jieba 分词 + 自建倒排索引表 方案。
简单说，就是：

1. 写个 Python 脚本，用 jieba 对每篇文章分词
2. 把词和文章 ID 存入一张 article_keywords 表
3. 搜索时，先分词，再查这张表，按 TF-IDF 排序（简易版）

性能？别提了。第一次全量构建花了 18 个小时，期间 DB CPU 飙到 95%。运维大哥在群里@我：“再跑一次我就把你工位搬到机房去。”

但神奇的是，效果居然能用。虽然远不如 ES，但在小流量场景下，用户反馈“比以前好找多了”。

后来我买了本《搜索引擎技术基础》，睡前翻几页。不是为了这个需求，而是突然意识到：很多“不可能”的需求，其实是你知识边界外的常态。

---

“这个按钮要能一键生成 PDF、Excel、Word，三种格式，实时导出”

去年夏天，我在一家 SaaS 创业公司当技术顾问（也就是临危受命救火）。客户是一家传统制造企业，他们的老板亲自提了个需求：

“销售同事经常要给客户发报价单。现在要导出三次，太麻烦！我要一个按钮，点一下，三种文件同时下载！”

听起来简单？天真。

真实情况是：

• PDF 要带公司 logo 和水印
• Excel 要保留公式（比如总价=单价×数量）
• Word 得是 .docx 格式，方便客户修改
• 数据来自三个不同微服务，还要合并
• 单次导出可能涉及上万条记录

更要命的是，他们服务器只有 2G 内存。

我试过用 Apache POI + iText + docx4j 三件套，结果 OOM（Out of Memory）错误满天飞。线上日志里全是：

java.lang.OutOfMemoryError: Java heap space
	at com.itextpdf.kernel.pdf.PdfStream.<init>(PdfStream.java:65)

那周我天天做梦都在调 JVM 参数。

最后解决方案很“土”：

1. 异步生成：点按钮后，返回“任务已提交”，后台慢慢做
2. 分块处理：每 1000 条一批，避免内存爆炸
3. 临时文件缓存：生成完存到 OSS，前端轮询状态
4. 压缩包打包：三种文件打成 zip 一起下载

上线那天，客户老板亲自打电话来夸：“小伙子，厉害啊！比我儿子还会弄电脑！”

我哭笑不得。其实哪有什么厉害，不过是把“实时”偷换成“近实时”，把“同步”包装成“异步” —— 这才是后端工程师的生存智慧。

---

为什么我开始读更多“没用”的书？

说实话，这些奇葩需求一开始让我很烦躁。觉得产品不懂技术，老板瞎指挥，团队在浪费生命。

但慢慢发现，真正的问题从来不在需求本身，而在我们如何应对它。

离职前最后一次 1on1，我的 mentor（也是前 CTO）对我说：“你技术很强，但有时候太执着于‘正确’。现实世界里，80% 的系统都是在妥协中跑起来的。”

这句话点醒了我。

于是我开始重读那些曾经觉得“理论脱离实际”的书籍：

• 《Clean Code》教我如何在混乱需求中保持代码可维护性
• 《Release It!》让我明白：能上线的烂系统，好过完美的 PPT 架构
• 《The Pragmatic Programmer》里那句“Programmers are Storytellers”——我们其实在帮业务讲一个技术能实现的故事

我把这些书放在床头，每天睡前看 20 页。不是为了跳槽涨薪，而是想找回刚入行时那种“用代码解决问题”的纯粹快乐。

---

给还在战斗的后端兄弟们一点建议

如果你也在被奇葩需求折磨，不妨试试这几招：

1. 把“不能做”换成“怎么做成本最低”

产品经理要的是结果，不是技术方案。你告诉他“MySQL 不支持”，不如说“我们可以用缓存+定时任务模拟，三天能上线”。

2. 建立“需求防火墙”

我现在会给每个需求加个评估维度：

维度	说明
技术债	会不会导致系统腐化？
运维成本	需要额外监控/告警吗？
用户价值	真的有人用吗？还是自嗨？
替代方案	有没有更简单的 MVP？

3. 保护自己的心力

加班可以，但别透支热情。我见过太多优秀的后端，被无意义的需求磨平了棱角，最后只会写 CRUD。

---

写在最后

前几天整理旧硬盘，翻到五年前写的日报：“今天和产品吵了一架，因为他说 Redis 能当数据库用……”

现在想想，其实产品也没错。他只是站在用户视角，希望功能快点上线。而我们后端，是那个在背后默默兜底的人。

创业之后，我自己也要提需求了。这才知道，原来每个“不合理”的背后，都有业务的焦虑和市场的压力。

所以啊，别嘲笑那些奇葩需求。它们是你职业生涯的磨刀石—— 磨掉你的傲慢，留下你的韧性。

此刻窗外雨停了，咖啡也凉了。我把书合上，准备回去继续搭我的新项目。这次，我要做一个既满足业务、又让自己睡得着觉的系统。

毕竟，代码会老，需求会变，但那份对“好系统”的追求，永远年轻。

共勉。