发布生产环境后 产品称用户创建的agent“头像丢失”.
我打开控制台 发现一个网络请求超时的异常 便认为是网络的问题 让产品多刷新几次就好了.可是过了一段时间 他报告了最新的情况 即有一部分agent的头像正常显示 另一部分是灰色的(antd的头像组件).
我打开网络面板 筛选"图片" 发现只有无论成功还是失败 都只有寥寥数个请求 和当前页面几十个agent的情况完全不符 遂怀疑是数据问题———然而后端的接口正确地返回了头像链接.
此时有人提醒我 接口返回的很多数据是'/assets/'开头的 少数则是用户上传到云存储的 以https开头 而"图片"类型的网络请求 全都是https开头的 是不是前端的资源出了问题？我受此启发 查看"文档"类型的网络请求 果然发现了一系列/assets/xx/.png的请求 显然是nginx将这些请求都重定向到了index.html而非对应的静态资源.
不过 nginx配置几乎没人动过 上次更改还是三四个月前 把单引号改成了双引号.此外 配置中先"try files"再定向到index.html是完全符合预期的.这说明 前端的静态资源里根本就没有这些图片！
正在我思考vite的bug之类的东西时 我突然意识到这些图片的名称都后缀了一串哈希值.此时我回想起国庆节前的一周 需求像拉稀一样从雇主的嘴里喷涌而出 包括但不限于UI的全面改版 其中就有十分钟三变的"Agent默认头像调整" 当时我为了省事 直接把图片放在了组件的文件夹里并通过import引入 这就导致这些图片会vite重命名 并且即便是同一图片 两次打包的哈希值都不同.用户创建agent时 我会将图片的url提交给后端 如果用户没有上传头像 就提交默认头像.而第二次打包后 默认头像的文件名已经变化 上次提交的"默认头像"自然也访问不到对应的资源.
解决方案:
1.后端清洗数据 将所有以'/'开头的头像都改为字符串'default'
2.前端做判断 无论创建还是展示 若头像url是'default' 则展示对应类型的默认头像
