Blazor WASM中Resx文件的旧静态使用方式存在什么问题？

• 文化切换适配问题
  桌面端常用的PublicResXFileCodeGenerator生成的强类型资源类，默认依赖Thread.CurrentThread.CurrentUICulture读取文化配置，和Blazor的运行机制不兼容：Blazor WASM是单线程运行时，文化切换不会自动更新静态资源属性的缓存；Blazor Server是多用户共享服务实例，全局静态的资源类无法支持不同用户的独立文化配置，很容易出现多用户语言串扰、切换语言后界面不刷新的问题。
• 首屏加载性能损耗
  强类型Resx的所有文化资源都会被嵌入到编译后的程序集中，Blazor WASM首屏加载时需要下载全量的多语言资源，大幅增加首屏体积。而IStringLocalizer原生支持按需加载仅当前用户使用的文化资源，可有效降低首屏加载耗时。
• 扩展性差
  强类型Resx是编译时静态生成的，后续如果需要对接数据库、远程配置中心等动态翻译数据源，完全无法适配。而IStringLocalizer是抽象接口，你可以自定义实现类无缝替换默认的Resx实现，业务代码不需要做任何修改。
• 视图隔离支持不足
  官方的IStringLocalizer方案原生支持按组件、按页面拆分资源文件，比如你可以给Pages/Index.razor单独建Index.razor.resx资源，注入时自动匹配对应范围的资源，不需要全局维护一个大的资源文件，大型项目的可维护性更高。

你担心的重构安全性问题完全可以通过工具链解决，目前有成熟的源生成器、T4模板方案，可以自动根据Resx文件生成强类型的包装类，既保留MyResource.MyTranslationKey的强类型、重构安全的特性，又能兼容IStringLocalizer的所有能力，不需要直接写魔法字符串。

内容的提问来源于stack exchange，提问作者RWJ