为何旧版Java的System.getSystemProperty("os.name")无法正确识别Windows11

os.name 是JDK在启动时通过原生平台接口填充的系统属性，在Windows环境下，Java 18及更早版本的JDK是调用Win32 API GetVersionEx 获取系统版本号，再映射为对应的名称字符串。
微软从Windows 8.1开始为GetVersionEx加入了兼容性兼容层：如果可执行程序没有在内嵌manifest中明确声明对更高版本Windows的支持，API会返回被降级的旧版本号，避免老程序因硬编码版本判断逻辑崩溃。Java 17及更早版本的JDK原生启动程序（java.exe、javaw.exe等）没有添加Windows 11的兼容声明，因此拿到的版本号被Windows自动判定为Windows 10对应值，最终os.name返回错误结果。
Java 19修复该问题的逻辑也很直接：一是更新了JDK可执行文件的内嵌manifest，明确声明支持Windows 11；二是替换了版本获取逻辑，改用不受兼容层影响的新版API查询版本，因此可以正确识别Windows 11。
Apache commons-lang3等第三方库直接读取os.name属性取值，自然会和JDK返回的错误结果保持一致。而systeminfo命令是直接读取系统内部版本配置输出结果，不受应用程序兼容层影响，所以能返回正确的系统名称。

按可靠性、侵入性从优到劣排序：

• 首选方案：为使用的旧版本JDK的所有可执行文件（java.exe、javaw.exe，服务端场景还需覆盖javaws.exe等相关二进制）内嵌Windows兼容manifest，明确声明支持Windows 11。该方案无需修改任何业务代码，所有依赖os.name的逻辑（包括第三方库）都能直接拿到正确结果，无额外运行时开销，也不存在解析逻辑的兼容问题。
• 次选方案：在程序启动的最早期（所有依赖os.name的逻辑执行前），通过可靠方式获取正确系统版本后，调用System.setProperty("os.name", "Windows 11")手动覆盖属性值。该方案需要自行处理版本判断逻辑，且要保证属性覆盖时机足够早，否则会出现部分逻辑读到旧值的问题。

• 解析systeminfo命令输出不推荐作为常规方案：该命令冷启动执行耗时通常在数秒到十余秒，会大幅拖慢程序启动速度；同时不同语言本地化的Windows系统输出字段名、格式差异极大（例如简体中文系统对应字段为OS 名称:而非OS Name:），多语言适配成本极高；部分精简版系统、Server Core模式系统还会裁剪systeminfo的输出内容，存在解析失败的风险。
• 旧版JDK不通过环境变量、注册表识别系统版本的原因很明确：Windows默认没有提供存储系统正式名称的全局环境变量，无法从环境变量拿到准确值；而注册表中存储版本信息的路径、键值属于系统内部实现细节，微软从未承诺跨版本保持结构稳定，直接读取存在长期兼容性风险。JDK作为跨平台运行时，优先选择官方公开、承诺稳定的系统API获取信息，在Windows 11发布前的旧版本JDK自然不会预设对未发布系统的识别逻辑，也不会采用读注册表这类不稳定的实现方式。

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