2026-01-04至2026-01-11
这周连上六天班，提不起精神，整个人特别疲惫，直到今天还是这样。
博客 Memos
千呼万唤始出来，总算是把博客的 Memos 模块做出来了。
在基础展示上，实现了新增、编辑和删除功能；同时集成了 PWA，方便我直接用手机发布 Memo。图片上传也做了优化，包括压缩和转 WebP，整体算是差强人意。
当然还有好几个优化的待办项，优先级倒是不高，等有空再做了。
问题排查
每隔一段时间，就会碰到几个离谱的线上问题。
这次产品反馈，有一个加拿大国籍的客户开户，在 OCR 人脸认证仅失败一次的情况下，就直接通过照片上传的方式走完了整个开户流程，最终在人工审核被拦截，需要我们定位原因。
按正常产品逻辑，加拿大在我们支持的 OCR 国家内，每个用户有六次认证机会，只有在六次都认证失败后，才允许走照片上传。
下午先是后端在排查数据问题，他发现这个用户调用了一次人脸认证初始化接口，却没有调用查询结果接口，于是让我看前端流程，分析可能原因。 这块逻辑并不复杂，在 APP 内 H5 是通过调用桥唤起原生模块做的人脸认证，依赖桥的成功回调触发 H5 调用接口查询结果。我据此判断问题出在了 APP 侧，便拉 APP 的同事查看这块逻辑。APP 的逻辑是在初始化之后调用的第三方 SDK，所以这个问题的线索到这儿就断了。
吃完晚饭我意识到，方向被带偏了。接口调用的问题只是因为用户认证失败，问题的关键在于为什么能绕过六次认证的逻辑。于是仔细分析了一遍前端代码（当然，配合 AI），总结出只有以下三个场景会走照片上传：
- 某个特殊渠道进入开户；
- 用户国籍不是人脸认证支持的国家；
- 人脸认证次数超过六次。
通过后端日志判断，三者都不成立，思路又一次被卡住。 我问后端要了对应几个接口的日志，仔细看了几遍，终于发现了「华点」：用户在文件上传时，国籍的传参竟然是 ARE（阿拉伯联合酋长国），而这个国家在业务中并不支持人脸认证。 我立即按照这个思路，到测试环境复刻了一下用户的操作：
- 进行一次人脸认证失败
- 再选择一个不支持人脸认证的国家
- 上传照片，保存数据进入下一步
- 返回上一步，把国籍改回加拿大
- 再次保存数据，继续流程。
至此，限制成功被绕过，我马上在群里同步了原因以及复现步骤。
呼，排查一个问题如同破一个诡案，找到真相那一刻倒也让我欣喜。
潜伏
这周猛猛看《潜伏》，真是难得的好剧，只剩下最后两集，等看完再好好总结一下，写点什么。
除了主角之外，最喜欢吴站长这个角色，典型的领导的艺术，贡献了全剧我最喜欢的一句台词：「那个时候，我还爱好哲学。」
梦
最近每天都做梦，像是回到了一两年前的多梦状态，只是没有以前的那些魔幻色彩，最近梦里相对真实的场景，却满足着我现实中的奢望，结合这冬天的冷空气，真是让我不想起床，只想赖在被窝。