用途
该技能用于诊断和修复桌面应用捆绑原生库时出现的一类隐蔽冲突：随应用一起打包的通用基础库（工具/集合库、压缩库、加密库等）会抢占进程内共享对象名（Linux 上即库动态段中记录的 soname），此后该名称在整个进程生命周期内归先加载的副本所有。由于应用的原生库通常加载较早，捆绑副本会“赢”得该名称。
故障表现
冲突发生时不会立即报错，而是在后续与原生库无关的代码中失败：平台 API 打开同族系统库时，系统副本需要捆绑的旧副本未导出的符号，加载失败，平台随后将整个 API 标记为在剩余进程生命周期内不受支持。
文中给出的 Linux 实例：捆绑的媒体库携带了一个基于较旧发行版构建的工具库。JDK 的桌面集成 API（java.awt.Desktop）在首次使用时探测其原生后端；在系统副本较新的宿主上，探测因未定义符号而失败，错误信息指向同族的第三个库。此后 JDK 报告桌面 API 不受支持，所有外部链接调用点同时失效。
修复方式
修复分两步，按顺序执行。
第一步（根治）：在打包暂存阶段排除系统基础库。示例排除列表包含 libc.so.6、libm.so.6、libdl.so.2、libpthread.so.0、librt.so.1、ld-linux-x86-64.so.2、libgcc_s.so.1、libstdc++.so.6、libz.so.1、libbz2.so.1.0、liblzma.so.5，并配合 is_system() 函数判断。
第二步（临时规避）：在捆绑包重建期间，强制受影响的平台 API 在任何原生库加载之前完成探测。平台会缓存首次调用的探测结果，因此在仅映射系统副本时运行探测即可固定答案。示例代码在 runApp() 中先调用 java.awt.Desktop.isDesktopSupported()，再执行 startEverythingElse()。同时应在旁边写明移除条件：一旦基础库从捆绑包中排除且原生压缩包重新发布，即移除该预热调用。
常见陷阱
- 本机无法复现，原因有二：若捆绑包未在本地暂存，加载器会静默使用系统级副本，根本不会发生名称抢占；即便暂存了捆绑包，故障还需要宿主的系统副本比捆绑副本更新——固定到旧发行版的构建容器产出的捆绑包在该发行版上正常，在当前发行版上则损坏。因此应记录每个加载的原生库的解析路径（NativeLibrary.getInstance(name).file），该日志是区分“使用捆绑包”与“静默使用系统副本”的唯一依据。
- 错误信息指向错误的库：报错文本指向同族中第三个被传递加载的成员，而非失败的 API，也不是肇事的副本。找不到的符号实际位于你捆绑的库中：较新的系统版本导出该符号，较旧的捆绑副本不导出，而你的副本占用了名称。应按库族匹配，而非按消息中的名称匹配。
- 排除列表往往只围绕 C 运行时编写便停止。实际规则更宽：宿主进程也会加载的任何东西都应排除，包括 GUI 工具包自身的桌面集成在启动很久之后才在运行时打开的内容，这些对原生库的依赖遍历不可见。
- 能力损坏不能静默失败。当平台 API 变为不受支持时，同一能力的两个调用点可能表现相反：一个是没有 else 的 if，导致应用所有外部链接静默无操作；另一个是 UI 框架自身的链接处理器在第一行调用该 API 并直接从点击处理器抛出异常，导致应用崩溃。应为该能力提供回退链和可见的最终兜底，例如先尝试桌面 API，再尝试按操作系统排序的系统启动器，最后记录错误并提示用户。按各启动器存在的可能性排序，且将成功启动视为足够，不要等待退出码阻塞 UI 线程。
- 捆绑进程 C 运行时的第二份副本是同一类 bug 但更难处理：宿主运行时在你的代码运行前已映射，一个进程内的第二份副本无法正常工作。
- 修复进入 diff 不等于修复进入生产。文中实例是 glib（libglib-2.0.so.0）未列入排除列表，导致在系统 glib 较新的宿主上破坏 java.awt.Desktop。把缺失名称加入列表只是一行改动，在评审中看似完整修复，但用户实际加载的是单独发布、在构建其他位置按校验和固定的预构建归档，并非构建时从暂存脚本实时生成。添加 glib 排除的 PR 明确表示该改动“只修改暂存脚本”，要生效仍需重建、重新发布归档并更新固定的校验和，而这些均未在同一改动中完成，也未在合并前针对真实暂存构建验证。在所有这些步骤完成前，每个现有安装以及在下一次原生库升级前构建的新安装都会继续加载未修复的捆绑包：正确的 diff，零实际效果。应将“脚本中已排除”与“发布物中已排除”视为两个独立主张，并专门要求第二个主张的证据。
验证方法
- 列出实际捆绑的内容并人工阅读，而非依赖依赖遍历：STAGED_NATIVE_DIR=mpv-natives/linux-x64; ls "$STAGED_NATIVE_DIR/lib"。标准桌面已提供的内容都是候选排除项。
- 搜索脆弱能力的每个调用点，检查是否都有 else：SRC=composeApp/src/jvmMain; grep -rn "isDesktopSupported|Desktop.getDesktop" --include='*.kt' "$SRC"。
- 在加载时记录每个原生库的解析路径，并在打包构建中读取该日志。
- 在比构建环境更新的宿主上测试。当前发行版发布的容器镜像是最廉价的复现方式——故障需要系统副本比捆绑副本更新，因此等于或早于构建环境发行版的宿主都会通过。
- 排除生效后，确认依赖闭包仍可解析且库仍能初始化——丢弃原生库真正需要的库的暂存步骤会在下一个用户处失败。应在构建中设置加载并初始化的冒烟测试作为门禁。