创业前端架构：合规、可信、安全三位一体

　　跟产品吵。上个月十六号下午三点零七分，PM 在钉钉发了个新需求——「隐私协议弹窗必须带欧盟旗帜图标」。我回了个问号，他秒回「法务说的」。我截图甩过去：「你让法务看看 GDPR 第二十五条第二款，说的是 design principle，不是 icon position」。他回了个握手表情。二十分钟后，测试在群里@所有人：「弹窗点了同意，埋点没打」。我说「先看 network tab」，前端小陈直接切了生产环境 console 打 log，结果发现埋点 SDK 被他昨天手抖关了灰度开关，但只推了 72%，剩下那 28% 的实例还在走旧链路——就是那种「用户点了，日志里啥也没有，监控里也看不出哪断了」的断点。我原以为是 consent token 没透传，结果是 SDK 初始化时判了 window.__DEBUG__，而这个变量在灰度开关切半的状态下，一半机器有、一半没有。

文章配图，仅供参考

　　咖啡杯上印的公司 logo 已经掉漆了，左边翅膀少了一撇。上周五 oncall 手机震了一下，不是告警，是物业群通知「三楼饮水机滤芯到期」。我顺手去倒了杯水，路过监控大屏，看见右下角一个无关曲线——那是前端错误率折线图旁边那个「JS bundle 解析耗时」的小曲线——抖了一下，十八毫秒。没人管它。但它确实抖了。就像我们上线时总漏掉一件事：cookie 的 SameSite 属性在 Safari 上会静默失败，而 QA 测试机全用 Chrome。这事我说不准，但我知道每次 iOS 用户反馈「登录后跳首页」，八成是它干的。

　　发版流程现在是这样：第一步，前端把 src 目录打 zip 包；第二步，扔进 Jenkins 脚本，跑 lint → 构建 → 单测（只跑 mock 掉后端的那十七个）→ 往预发推镜像；第三步，在预发手动点三次「同意隐私协议」再清 localStorage，然后切到 DevTools Application Tab 看 cookies 列表有没有多出 gdpr_consent_v2 字段——如果没多，说明 env 配错了，得回退，重来。这三步，每一步都卡过人。前天小陈卡在第二步，因为 package-lock.json 里有个依赖的 integrity 值是 base64 编码的 sha512，但 Jenkins 容器的 node 版本不支持那个 digest 算法，于是构建完发现 index.html 里 script src 是空的。三百七十二次调用，全是 404。没人报错，页面只是白屏。他说「我以为是 CDN 缓存」，其实不是。是 build 步骤 silently failed，而我们的脚本没设 exit code check。

　　工资条上绩效系数今年砍了 0.13，HR 说是因为「战略对齐度」。我对齐个屁。我对着 KPI 文档抄了一小时「提升前端可审计性」，结果转头就得给 PM 抄写十页《弹窗交互规范 V3.2.1-b》，里面有一条：「用户滑动超过屏幕高度 60%，则自动勾选『我已阅读并同意』」。我问是不是需要上报 UA 和 viewport-height 给法务备案，PM 说「不用，我们走的是『默认合理推定』路径」。我差点笑出声——去年 Q3 合规审计报告里写的正是「禁止任何非显式行为推定用户意愿」。但报告是 PDF，没人点开，连签字扫描件都是 PNG，压根搜不到关键词。

　　可信最骗人。你以为加个 Subresource Integrity 就可信了？你 integrity hash 是自己算的，算的时候用的是开发机上的 webpack，但上线走的是 Docker 内的 webpack —— 那台容器里装了 python3.9，而 Python 的 json.dumps 默认会对 dict key 排序，webpack 依赖里恰好有个插件读了某个 JSON 描述文件……于是打包出来的 JS chunk content-hash，每天差那么一丁点。你本地验得再稳，线上就是挂。我们上周五凌晨修了一个 bug：首屏 SVG 图标渲染异常。查了四小时，最后发现是 build 容器的字体配置导致 svg `` 元素 baseline 计算偏移两像素，而那个 offset 被当作 CSS custom property 写进了 style 标签——整个链路里没一个环节校验 integrity，连 devtools 都认它是「valid SRI」。这就是可信：看上去防得住，实际上防不住，还让你误以为防住了。

　　安全组上礼拜终于把「前端敏感字段脱敏」需求排进 backlog。我盯着他们 PRD 里写的「所有含 id_card / phone / bank_account 字样的变量名需在运行时自动 toString().replace()」看了十分钟。后来我直接找 DBA 老李借了数据库连接串，在从库抽了三百行 test_user 表数据，拿正则 grep 了字段注释——发现他们自己建表时写的是「user_phonenum」和「idcard_no」。所以前端永远 match 不到。老李边倒水边说：「我们当年还写过 id_num_hash」。我没接话。水开了，我关了烧水壶。监控大屏上那条十八毫秒的曲线又抖了一下，这次是向下。

　　我现在改了习惯：每次 PR 描述第一行必须写「本次修改影响哪些合规条款/可信凭证/安全检测项」，哪怕写「不影响，纯 UI 对齐」也得写。测试小王今天提了个 bug：「点击注销后，localStorage 还留着 access_token」。我看了眼代码，token 清除逻辑被包在一个 try-catch 里，catch 里什么也没做。我把它删了，补了句 comment：「此处不应 suppress error，否则无法感知 token purge 失败，进而导致可信断言失效」。这话写得比需求文档还工整。但我心里清楚，下周五发版时，可能又会有人把这段删掉——因为「影响首屏性能，FID 涨了三毫秒」。

　　所以这三位一体，不是架构目标，是验收门槛。你通不过，就没资格上线；你过了，也不代表你真的有。它筛掉的不是技术差的人，是懒得较真的。优胜劣汰——但汰掉的往往是最先发现问题的那个。明天我打算把 SRI 验证逻辑拆出来，单独起个微前端沙箱跑，不跟主应用混。至少那边挂了，不影响首页。至于怎么跟产品解释「为什么多一个 iframe 就能过等保」……我还没想好。先喝口水。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!