那些年，我遇到的奇葩需求
本文作者：前 Android 开发，现 Flutter 跨平台打工人。日常靠 ChatGPT + Claude 续命，最近一边改 Bug 一边刷 LeetCode 准备跳槽。重度关注架构设计和代码质量，但常常被“明天上线”逼得写出自己都看不下去的屎山。
写这篇文章的契机，其实挺偶然。
上周五晚上 10 点半，刚在 VS Code 里跑完一套单元测试，准备关电脑去吃泡面，结果 Slack 弹出一条消息：
“Hey，有个新需求要加，用户希望 App 能读取本地钱包地址，然后调用一个 JS 脚本自动签名交易……下周三上线，行吗？”
我当时盯着屏幕愣了三秒，脑子里只剩下一个念头：这届产品经理是不是把《区块链白皮书》当睡前读物了？
作为一个从 Android 转型到 Flutter 的老油条，我自认为见过不少“骚操作”——比如要求动态换肤但不给资源包体积预算，或者让 iOS 和 Android 共享一套动画逻辑却不考虑帧率差异。但这次的需求，真的让我重新定义了“离谱”。
于是我想，不如整理一下这些年踩过的奇葩坑，顺便聊聊这些经历如何影响了我的技术视野、求职方向，甚至对“好代码”的理解。
奇葩需求 No.1：在 Flutter 里跑 JavaScript？
是的，你没看错。不是 WebView，不是 Duktape，而是原生执行一段用户上传的 JS 脚本，还要能访问设备密钥、网络状态、甚至蓝牙信息。
起因是一个所谓的“去中心化身份验证”项目。客户声称要打造“Web3 时代的轻量级钱包”，但预算只够招两个前端。于是他们决定：用 Flutter 写主 App，然后让用户自己写 JS 脚本来定义交易逻辑——听起来很酷，对吧？
但现实很骨感。
Flutter 本身并不支持直接执行 JavaScript（Dart VM ≠ JS Engine）。我们第一反应是用 flutter_js 这个社区库。结果一试就炸：
final js = await JsRuntime.create();
final result = await js.evaluate("navigator.bluetooth"); // TypeError: Cannot read property 'bluetooth' of undefined
JS 引擎里压根没有浏览器环境！更别说访问原生 API 了。
解法？硬桥接。
我们被迫搞了个“JS-Flutter 桥”：把 JS 脚本里的特定函数名（比如 getDeviceId()）映射成 Dart 的 MethodChannel 调用。用户写：
const deviceId = await native.getDeviceId();
我们在 Dart 层拦截这个调用，通过 MethodChannel 获取真实设备 ID，再塞回 JS 上下文。
但问题来了：安全性怎么办？ 用户脚本要是写了个死循环，整个 App 就卡死。更别说恶意脚本读取剪贴板、偷偷发请求了。
最后我们不得不加了个沙箱层，限制 JS 只能调用白名单内的函数，并设置执行超时（500ms 自动 kill）。上线后虽然没崩，但性能堪忧——每次交易都要初始化 JS 引擎，冷启动 800ms+。
这段经历让我深刻意识到：跨平台不是万能胶水。有些需求，从架构上就是反模式。后来我在面试时被问到“如何评估一个需求的技术可行性”，我就拿这个案例讲了 15 分钟——面试官眼睛都亮了。
奇葩需求 No.2：“这个功能要用区块链存证！”
去年双11前，老板突然召集全员开会，说要“拥抱 Web3”。具体任务是：用户每次下单，都要把订单哈希写入某条国产联盟链。
我当场就懵了：“咱们是电商 App 啊，又不是数字藏品平台……而且链上写一次要 2 秒，用户等得起？”
产品经理拍胸脯：“技术细节你们搞定，老板说这是‘战略级创新’。”
于是我们开始调研。那条链只提供 HTTP API，且要求私钥本地保管。为了安全，我们不能把私钥硬编码进 App——那就只能让用户自己导入钱包。
结果呢？90% 的用户根本不知道“私钥”是什么。剩下 10% 导入后，发现每次下单要手动确认三次弹窗（App → 钱包 → 链），转化率直接腰斩。
更搞笑的是，运维同事抱怨：“你们写的链上日志太多了！节点存储快爆了！” 我们这才发现，原来那条链的区块大小限制极低，频繁写入会导致节点拒绝服务。
最后这个功能上线两周就被砍了。但代价是：我熬了三个通宵写的链交互模块，成了代码库里最没人敢碰的“祖传代码”。
这件事教会我什么？
- 别为 buzzword 技术买单：区块链适合不可篡改、多方共识的场景，但普通订单完全可以用数据库 + 数字签名。
- 技术选型要问“为什么”：如果产品经理说“因为竞品用了”，请直接反问：“他们因此多赚了多少钱？”
现在我面试时，只要听到“我们想用区块链做 XXX”，都会多问一句：“你们有算过 gas 成本和用户体验的 trade-off 吗？” —— 能答上来的团队，往往真的懂技术。
奇葩需求 No.3：Android/iOS/Web 三端共享一套业务逻辑
这个需求听起来很合理，对吧？毕竟我转 Flutter 就是为了“一次编写，多端运行”。
但问题出在细节。
客户要求：所有业务规则（比如优惠券计算、风控拦截）必须用 JavaScript 编写，然后在三端通过各自的 JS 引擎执行。理由是“前端同学最熟悉 JS，维护成本低”。
我内心 OS：所以 Dart 是空气？Flutter 的类型安全和热重载是摆设？
但老板点头了，只能干。
我们搞了个“JS 规则引擎”，把核心逻辑抽成 .js 文件，打包进 App。Android 用 V8，iOS 用 JavaScriptCore，Flutter 用 flutter_js —— 表面统一，底层各玩各的。
结果？同一段 JS，在三端跑出三种结果。
原因包括但不限于：
- 浮点数精度差异（iOS 的 JSC 对
0.1 + 0.2处理和 V8 不同） - 日期解析行为不一致（
new Date("2023-08-01")在 Android 上返回 UTC，iOS 返回本地时区） - 正则表达式引擎差异（
\s在某些版本不匹配中文空格）
我们不得不写了一堆 polyfill，还加了“规则校验器”——每次 JS 更新，先在三端跑一遍 test suite，结果一致才允许发布。
最崩溃的是，有次线上事故就是因为 JS 里用了 Array.prototype.includes，而某个低端 Android 机的 WebView 版本太老，不支持这个 API，直接 crash。
那段时间我天天梦见自己在写 TypeScript，醒来第一件事就是检查 CI 是否 green。
反思：共享逻辑 ≠ 共享语言
现在我明白了：跨平台的核心是抽象，不是复用代码。更好的做法是用 Protocol Buffer 定义接口，各端用各自擅长的语言实现。JS 适合 UI 交互，但不适合做高可靠业务逻辑——尤其当你无法控制运行环境时。
这件事也让我在准备跳槽时特别看重团队的“技术决策流程”。如果一家公司让非技术人员拍脑袋定技术栈，我基本就 pass 了。
奇葩背后：我们到底在对抗什么？
回顾这些奇葩需求，我发现它们往往源于几个共同点：
| 问题类型 | 典型表现 | 应对策略 |
|---|---|---|
| 技术跟风 | “别人都用区块链/AI/元宇宙，我们也得上” | 用数据说话：ROI、用户反馈、维护成本 |
| 职责模糊 | 产品经理写技术方案，开发只负责“实现” | 推动 RFC（Request for Comments）机制 |
| 短期 KPI 驱动 | “双11前必须上线，细节以后优化” | 明确 MVP 范围，拒绝无限 scope creep |
作为开发者，我们常被当作“需求翻译机”——把模糊的商业语言转成代码。但真正有价值的工程师，应该成为技术守门人。
这也是我为什么越来越重视架构设计。一个清晰的分层（比如 Clean Architecture）、严格的类型系统（Dart 的 null safety 救我狗命）、完善的测试覆盖，能在需求乱飞时守住底线。
给同行的建议：如何在奇葩中成长？
把坑变成简历亮点
面试时别说“我做过区块链项目”，要说“我设计了一套 JS 沙箱机制，在保证安全的前提下支持用户自定义脚本，降低 70% 的客服投诉”。用结果说话。善用 AI，但别依赖
我用 ChatGPT 快速生成 JS 沙箱的原型代码，但它不懂 Flutter 的生命周期。最终方案还是靠自己 debug。AI 是锤子，但你要知道该敲哪颗钉子。建立自己的“技术红线”
比如我的原则：绝不写无测试的业务逻辑、绝不 hardcode 私钥、绝不承诺无法量化的性能指标。守住这些，才能睡安稳觉。分享即学习
写这篇文章的过程，让我重新梳理了那些混乱项目的脉络。技术分享不是炫耀，而是把经验内化成方法论。
最后：关于求职，我想说
最近刷题之余，我也在反思：为什么总遇到奇葩需求？是不是我待的团队不够成熟？
后来想通了：每个阶段都有对应的战场。初创公司要快速试错，大厂要稳如泰山。关键是你能否在混乱中提炼价值。
现在我看新机会，会重点问：
- 需求评审流程是怎样的？
- 技术债有量化指标吗？
- 团队如何做技术选型？
如果对方回答“老板说了算”或“先上线再说”，哪怕薪资高 30%，我也会犹豫。
毕竟，写代码是我吃饭的家伙，我不想让它变成一团浆糊。
写完这篇，泡面都凉了。但心里挺踏实——至少我把那些糟心事变成了文字，说不定能帮某个正在加班的兄弟少踩一个坑。
共勉。
评论 0