生产环境下，Web、H5、小程序、移动应用和桌面应用通常在发布前压缩、混淆、编译代码或剥离调试信息。当发生 JS 错误、崩溃或原生异常时，RUM 采集到的堆栈信息可能只包含压缩后的文件名、行列号、混淆后的方法名或内存地址，难以直接定位源码位置。通过上传符号表文件至 RUM，可以将这些不可读的堆栈还原为可读的源码信息。
什么是符号表文件
符号表文件是构建产物与源码、函数名、文件名、行号等调试信息之间的映射文件。将对应版本的符号表文件上传至 RUM 后，RUM 根据版本号、文件标识、Debug ID、Build ID、UUID 等信息匹配符号表文件，将不可读或难以理解的堆栈还原为可读的源码文件、方法名和行号。
为什么需要符号表文件
未上传符号表文件时，RUM 采集到的错误堆栈只能展示压缩文件名、混淆类名或内存地址，无法定位到具体的源码位置。上传符号表文件后，可以实现以下能力：
将压缩或混淆后的 JS 堆栈还原为源码文件、方法名和行列号。
将 Android 混淆后的类名和方法名还原为原始名称。
将 iOS 或原生崩溃的内存地址解析为函数名、文件名和行号。
按应用版本或构建版本管理符号表，定位不同发布版本的线上问题。
无需将 SourceMap 等调试文件暴露到公网，即可完成生产环境错误定位。
符号表文件可能包含源码路径、函数名、类名，部分 SourceMap 还可能包含源码内容。请妥善保管符号表文件，不建议将 SourceMap 直接发布到公网静态资源目录。
支持的文件类型
文件类型 | 适用场景 | 常见文件 |
SourceMap | Web、H5、小程序、React Native JS 错误堆栈还原 |
|
Android ProGuard/R8 mapping | Android Java/Kotlin 混淆堆栈还原 |
|
Native Symbol | Android 或其他原生 C/C++ 崩溃堆栈解析 | 未裁剪符号的 |
dSYM | iOS 崩溃堆栈符号化 |
|
PDB | Windows 或 PC 应用符号解析 |
|
如何获取符号表文件
不同平台和构建方式生成符号表文件的位置不同。请获取与线上发布版本完全一致的构建产物对应的符号表文件。
Web、H5 和小程序 SourceMap
SourceMap 通常由前端构建工具在生产构建阶段生成。常见文件后缀为 .js.map，一般与压缩后的 .js 文件位于同一构建产物目录，例如 dist/ 或 build/。常见生成方式如下：
Webpack：配置
devtool生成 SourceMap，例如source-map或 。Vite：配置
build.sourcemap。Rollup、esbuild、Parcel 等构建工具：开启对应的 SourceMap 生成配置。
TypeScript：如需保留 TypeScript 源码映射，请确保
tsconfig.json开启sourceMap。
生产环境推荐生成 SourceMap 后上传至 RUM，不建议将 .map 文件直接部署到公网静态资源目录。
Android ProGuard/R8 mapping 文件
如果 Android 应用开启了 ProGuard、R8 或 DexGuard 混淆，构建时会生成 mapping.txt 文件，用于将混淆后的类名、方法名还原为源码的原始名称。Gradle 工程的文件通常位于以下目录：
<project>/<module>/build/outputs/mapping/<build-variant>/mapping.txt例如：
app/build/outputs/mapping/release/mapping.txt如果项目使用多渠道、多 flavor 或多个 build variant，请上传与线上包对应 variant 生成的 mapping.txt。
Android Native Symbol 文件
如果 Android 应用包含 C/C++、NDK 或其他原生动态库，原生崩溃通常需要依赖 Native Symbol 文件解析。请保留构建过程生成的未裁剪符号信息的 .so 文件或调试符号文件，不要使用已被 strip 移除符号信息的线上 .so 文件作为符号表文件。常见目录包括：
<project>/<module>/build/intermediates/cmake/<variant>/obj/<abi>/
<project>/<module>/build/intermediates/ndk/<variant>/obj/<abi>/不同 Android Gradle Plugin、CMake 或 NDK 版本的输出目录可能不同，请以实际构建配置为准。
iOS dSYM 文件
iOS 应用构建时会生成 .dSYM 文件，用于将崩溃日志的内存地址解析为函数名、文件名和行号。请确保 Xcode 构建配置已开启 dSYM 生成：
Debug Information Format = DWARF with dSYM File常见获取方式包括：
本地 Archive 后，通过 Xcode Organizer 找到对应归档文件，查看或导出其中的 dSYM 文件。
从构建输出目录查找
$DWARF_DSYM_FOLDER_PATH下的.dSYM文件。如发布后需要补传，可从 App Store Connect 下载与该发布版本对应的 dSYM 文件。
建议每次发布 App 版本时，归档保存该版本对应的 .dSYM 文件。
Windows 或 PC 应用 PDB 文件
Windows 或 PC 应用通常使用 .pdb 文件保存调试符号信息。请在构建 Release 包时保留与可执行文件或动态库匹配的 .pdb 文件。
PDB 文件必须与线上发布的二进制文件来自同一次构建，否则可能无法正确解析堆栈。
获取符号表文件后的检查项
上传前，建议确认以下事项：
符号表文件与线上发布版本来自同一次构建。
应用版本号、构建号或发布版本与 RUM 上报信息一致。
SourceMap 与压缩后的 JS 文件一一对应。
Android mapping 文件对应正确的 build variant。
iOS dSYM 的 UUID 与崩溃日志的 UUID 匹配。
Native Symbol 未被 strip 移除调试符号。
文件未损坏，压缩包可正常解压。
符号表文件已安全归档，便于后续补传或问题排查。
后续步骤
获取符号表文件后，可以通过 CMS2 CLI 或构建插件上传至 RUM。具体上传步骤、参数说明和示例命令，请参见通过 CMS2 CLI 上传 RUM 符号表文件。