一句话......不。如果你在事故报告中看到这样一行字：
0 com.苹果.核心基金会0x 95 cb 046 b CFArrayAppendValue + 43
“+43”不是行号，而是从函数开始的内存位置。你编写的代码在编译后的二进制文件中根本不存在--编译器会优化和更改代码（至少在发布版本中），所以它通常与你编写的代码不匹配。
不幸的是，解决方案是为遇到崩溃的人提供一个调试版本，您可以远程调试或至少抛出NSLog（）语句来帮助跟踪它，和/或编写较小的方法。

我也遇到过这个问题，但只是因为我在查看比编译成崩溃的二进制代码更新的代码版本。当我返回源代码历史并找到相应版本的源代码时，行号完全匹配。

一个可能有用的建议-您可以使用dwarfdump命令检查.dSYM文件中的DWARF调试表，并确认它们与符号化崩溃报告的输出一致。
假设您在崩溃报告中看到代码地址0x100024914。请注意，这不是实际的内存地址，而是假设可执行文件加载到标准内存位置0x100000000的内存地址。出于安全原因，实际内存地址是随机的（通过添加一个称为"slide"的随机值），但是崩溃报告堆栈跟踪中的代码地址删除了该幻灯片。
现在您可以执行以下操作：

dwarfdump my_program.dsym/Contents/Resources/DWARF/my_program -lookup=0x100024914

您将得到如下所示的输出：

0x0001a9c3: Compile Unit: length = 0x00003367 version = 0x0004 abbr_offset = 0x0000 addr_size = 0x08 (next unit at 0x0001dd2e)

0x0001a9ce: DW_TAG_compile_unit
              DW_AT_producer    ("Apple LLVM version 10.0.1 (clang-1001.0.46.4)")
              DW_AT_language    (DW_LANG_C99)
              DW_AT_name        ("./my_program.c")
              DW_AT_stmt_list   (0x0000f323)
              DW_AT_comp_dir    ("/Users/sim/my_program")
              DW_AT_low_pc      (0x0000000100020f70)
              DW_AT_high_pc     (0x0000000100025f58)

0x0001cb5f:   DW_TAG_subprogram
                DW_AT_low_pc    (0x0000000100024070)
                DW_AT_high_pc   (0x0000000100024edb)
                DW_AT_frame_base        (DW_OP_reg6 RBP)
                DW_AT_name      ("my_program_do_some_stuff")
                DW_AT_decl_file ("/Users/sim/my_program/my_program.c")
                DW_AT_decl_line (1165)
                DW_AT_prototyped        (true)
                DW_AT_type      (0x0001b8ae "my_result_t")
                DW_AT_external  (true)

0x0001cbe2:     DW_TAG_lexical_block
                  DW_AT_low_pc  (0x0000000100024117)
                  DW_AT_high_pc (0x0000000100024ec1)
Line info: file 'my_program.c', line 1333, column 22, start line 1165

现在，如果您确认dwarfdump中的行号与符号化崩溃报告中的行号一致（我希望它会），这样，您就知道崩溃符号化引擎本身没有任何问题（Apple未记录的CoreSymbolication框架）-它正确地输出了可用的DWARF调试数据。（与开发人员的困惑相反，比如在另一个答案中提到的，查看了错误版本的源文件），看起来bug必须在编译器中（有点不太可能，但肯定是以前没有发生过的事情）。