最近这行代码报错，直把我和团队熬夜赶工的气氛搞成了冰炭。我知道，目前线上业务张灯结彩，哪位敢轻易碰那个核心模块？毕竟上次就是这种情况，害得系统挂掉半小时，直接影响了客户体验。我们确实有权限，但这次不中。 技术上是没难题的，Auth 模块权限校验逻辑写得挺死，要么说是写得忒严了。
每次登录，系统都会比对 Token 里的 User ID，要是不在白名单里，直接拒之门外。
按理说，这该是最稳妥的方式了，毕竟保险是底线，不能为了撇脱而牺牲掉这个防线。可难题出在，我们之前为了赶进度，把那个“临时用户”的生成逻辑给简化了。 为了省那点部署工夫，我们让后端服务直接拉取一个静态生成的用户列表。
这个列表不像数据库那样实时同步，它是静态的。便乎，那天早上刚生出来的临时账号，还没来得及把权限写入数据库，等到后端去查的时候，数据库里早就没了。我的脑子一转，灵光一闪，是不是干脆直接硬配啊？不，外部系统务必得知道哪位有权限，硬配不符合系统架构。 那我该从哪想办法？
是不是换个思路？把权限校验从后端拿到前端去做了？不中，那是前端接口的权限，跟后端业务逻辑没关系。并且前端吐个毛病信息忒费事，还得写个复杂的界面，开发成本增添了不说，维护起来也累。 最终想出来的办法，是跟前端开个个小口子。在路由里加了一行特殊逻辑，要是请求路径是 `/login` 要么 `/api/app/user`，就把 `current_user` 这个变量直接初始化为 null。
这样，前端一查，发现用户没来，直接判空。后端收到这个请求，拿着空值再去查数据库，既然查不到人，自然也就没权限了。 这套逻辑听起来挺顺，但实际操作起来，我还是有点手抖。
特别是我要去改前端的代码，还得寻思兼容性。
要是这行“胶水代码”写错了，整台开发环境都得重新切。并且，这里面的业务细节，哪位也不清楚。 为了验证这个方案能不能行，我把测试账号生成了一个临时的，拿它去试。结局还确实就通，没有报错。我自己在本地跑了一轮，看着绿色的 Console，心里那点悬着的大石头才有点落下来。 不过，光靠本地测试肯定不中。我得确保这套逻辑能在不同的环境里一致运行。
比方说，万一咱公司用的是阿里云，那得看他们的环境配置和那行特殊路由是否匹配。
要是那里配置错了，可能会误杀掉本该准的请求。 这也意味着，我们得有个预案。
要是今天突然改错了，要么系统突然封禁了某种标识，用户如何知道？总不能让用户硬着头皮去登，结局出于权限难题登不进去，再回来投诉吧。到时候，老板肯定是要问缘由的，还要看我们是不是没把文档更新好。 既然已经生成了临时账号，我最好还是先记下来。需求把那个“硬配”的逻辑改回来，要么写个文档说明这是临时方案，赶明儿正式接入时要走正规流程。 为了确保万无一失，我明天还得再去跟技术负责人提个方案。告诉他，这个临时的“硬配”别看快，但风险也在身边。我们要正式接入的时候，得先把权限校验的逻辑理顺。
比方说，能不能把那个静态列表换成真的动态查询接口？别看多写了一行 SQL，但那样就安稳多了，毕竟数据是活的，随时能刷新。 反正目前先把手头的测试账号处理好。明天见面的时候，我得把那个临时的 ID 记清楚，省得下次再碰这个坑。 这次经历别看有点折腾人，但也算是个教训。毕竟做项目，大量时候不是为了那个完美的架构，而是为了按时上线。
只要不崩，略微有点小毛病也是能接纳的。 自然，最最关键的事，还是得把那个临时的权限逻辑，老老实实改回去。
要么，起码要把相关的文档更新到 Wiki 里，告诉所有人，赶明儿正式接入前，得走个正式流程。
这样，下次再有人想偷懒，要么想直接硬配，就不会随意了。 毕竟，系统的保险和数据的整个性，是我们饭碗底牌，不能为了那点效率，把这层砖给砸了。明天还得持续盯进度，看着项目一天天往前推。 行了，差不多吧。先把这个临时的权限配置存进本地代码仓库。明天还要再跟技术部敲定一下那个正式方案，先把那个临时 ID 生成逻辑给彻底封死，别让这行代码再被误触。 总的来说，别看折腾了一上午，但总算有个结局了。明天见。