设置 CurrentUICulture 不会自动更新已有控件文本，必须重建UI或手动重绑定；资源文件命名、生成方式、访问路径须严格匹配，否则静默回退到默认语言。
直接改 Thread.CurrentThread.CurrentUICulture 不会让已存在的控件文本自动更新——这是最常被误以为“生效了”的假象。真正起作用的，是重建 UI 或手动触发资源重绑定，且资源文件命名、生成方式、访问路径三者必须严丝合缝，错一个就 fallback 到默认语言，还查不出错。
ResourceManager 构造时 baseName 和 assembly 必须配对正确
常见错误是手写 new ResourceManager("MyApp.Resources.Strings", Assembly.GetExecutingAssembly())，但实际生成的强类型类名可能是 MyApp.Properties.Resources，导致找不到资源；或者在类库中误用 Assembly.GetCallingAssembly()，结果加载的是调用方程序集而非资源所在程序集。
-
baseName是“命名空间 + 资源文件名（不含 .resx）”，比如Resources\Strings.resx在MyApp命名空间下，baseName 就是MyApp.Resources.Strings - 推荐永远用 VS 自动生成的强类型类（如
Properties.Resources），它内部封装了正确的baseName和Assembly，避免手误 - 调试时可打印
rm.BaseName和rm.ResourceSet?.Count，确认是否真加载到了对应 culture 的资源集
WinForms 切换语言后控件文本不更新？别只设 CurrentUICulture
设置 Thread.CurrentThread.CurrentUICulture = new CultureInfo("zh-CN") 只影响后续新建控件的资源读取，已有窗体、按钮、菜单项的文本早已缓存，不会响应变化。
- 最稳妥做法：关闭当前窗体，再以新文化启动新实例，例如
Application.Restart()或new MainForm().Show() - 若需原地刷新，可用
ComponentResourceManager手动重绑，但必须传入每个控件的Name（设计器生成的 Name 属性），且不能跳过嵌套控件（如toolStripMenuItem.DropDownItems需单独处理） - 切忌在窗体 Load 事件里读资源——此时
CurrentUICulture可能还没被设置，应放在构造函数末尾或Shown事件中
资源文件命名和生成操作不合规，运行时静默 fallback
VS 不会报错，但 ResourceManager 查不到匹配的卫星程序集时，会自动退回到主资源（如 Strings.resx），界面看起来“正常”，实则没走多语言逻辑。
- 文件名必须为
Strings.zh-CN.resx、Strings.en-US.resx，后缀中的区域码要和CultureInfo实例完全一致（zh-Hans≠zh-CN） - 所有
.resx文件的“生成操作”必须设为Embedded Resource，Access Modifier 设为Public - 检查输出目录：编译后应在
zh-CN\MyApp.resources.dll这类卫星程序集中看到对应资源，可用ildasm或dotnet ilc验证
GetString() 返回 null 而不是抛异常，容易埋雷
键不存在、culture 不匹配、资源未嵌入、baseName 错——这些情况全返回 null，如果代码里没判空，可能引发 NullReferenceException 或显示空白文本。
- 调用
rm.GetString("SaveButton", ci)前，确保ci不为 null，且ci.Name是你实际支持的语言（如"zh-CN"） - 建议封装一层：先尝试带 culture 获取，失败则 fallback 到无 culture 版本，再 fallback 到硬编码默认值，避免空字符串上线
- 特别注意 WPF 中
StaticResource绑定：它只在加载时求值，文化变更后不会更新，应改用DynamicResource或绑定到IStringLocalizer
最容易被忽略的点是：资源键名大小写敏感、.resx 文件里存 HTML 或 JSON 会触发 XML 转义，还有卫星程序集是否真的打进发布包——这些都不会报编译错误，但会让多语言在用户机器上彻底失效。
