ThinkPHP 模板里 `__STATIC__` 正常、`__JS__` 却 404，原来资源别名不是"一家人"

昨晚给老项目换 CDN，想着把静态资源统一迁到 OSS。配置完 `view_replace_str`，`__STATIC__` 顺风顺水，页面样式全正常。结果切到内页，几个交互全挂了，控制台一片红，`` 返回 404。

我第一反应是 OSS 路径配错了，对着 bucket 域名检查了八遍。又怀疑是浏览器缓存，Ctrl+F5 按到手指发麻。后来干脆在模板里写死完整 URL，居然能访问——说明 OSS 没问题，是别名解析环节出了岔子。

翻 `config/view.php` 才想起这项目的历史包袱。当初接手时，`__STATIC__` 是在框架默认配置里定义的，而 `__JS__` 和 `__CSS__` 是前任在公共控制器 `Base.php` 的 `initialize` 里用 `View::assign` 动态塞进去的。我新加的 CDN 配置只覆盖了 `view_replace_str`，控制器里的老逻辑纹丝不动，还在往模板里扔本地的 `/public/static/js/` 路径。

更坑的是这项目用了模板继承，父模板里用 `__STATIC__`，子模板里混着 `__JS__`。单看任何一个页面都对，但跨层级一组合，资源域名就"精神分裂"了。父模板从 CDN 拉，子模板往源站找，CORS 策略不同，直接触发拦截。

最后我把所有资源别名全收拢到 `view_replace_str`，控制器里的动态注入全部清掉。顺手加了个基类校验，初始化时比对一下 `__JS__` 和 `__STATIC__` 的域名前缀，不一致就抛日志。这种"半拉子"配置最折磨人，表面看起来都配了，实际各唱各的调。

你们项目里的资源别名是全集中管理，还是也散落各处？我这次算是被"历史遗留"上了一课。