simdjson项目在aarch64架构下的Fallback解析器问题分析

simdjson是一个高性能的JSON解析库，它利用SIMD指令集来加速JSON解析过程。最近在aarch64架构（如ARM64）的Linux系统上，用户发现该库的fallback解析器不可用，这引发了对库行为一致性的讨论。

在simdjson的设计中，fallback解析器是一个重要的组成部分。它作为后备方案，在当前硬件不支持任何优化的SIMD实现时提供基本功能。然而，在aarch64架构上，库的默认行为发生了变化：当检测到系统支持ARM64的NEON指令集时，库会完全禁用fallback解析器的编译。

这一行为变化源于库的编译时逻辑判断。simdjson会检查当前硬件平台是否支持某些特定的指令集实现（如ARM64、ICELAKE、HASWELL等）。如果发现有任何一种优化实现可以始终运行，就会默认禁用fallback解析器。这种设计优化减少了不必要的代码体积，因为在这些情况下fallback解析器确实不会被使用。

然而，这种变化与库的文档描述存在不一致。文档中多处提到fallback解析器"始终可用"，这给依赖这一行为的用户带来了困惑。特别是对于那些需要确保API行为一致性的应用场景，如测试环境或需要保证跨平台一致性的应用。

项目维护者提出了几种解决方案思路：

1. 恢复fallback解析器的编译，即使在不必要的情况下，以保持行为一致性
2. 引入新的内核别名概念，如"auto"，代表在当前硬件上自动选择最优实现
3. 将ARM64内核重命名为"generic"，并在fallback不可用时作为替代

从技术角度看，这个问题反映了高性能库设计中一个常见的权衡：优化资源使用与保持API一致性之间的平衡。对于大多数生产环境，在aarch64架构上禁用未使用的fallback解析器是合理的优化。但对于需要严格行为一致性的场景，可能需要提供明确的配置选项来覆盖默认行为。

这个问题也提醒我们，在编写库文档时，需要准确描述各种架构下的具体行为差异，避免给用户造成误解。同时，在变更默认行为时，应该考虑提供兼容性选项或明确的迁移路径。

对于使用simdjson的开发者，如果需要在aarch64架构上强制启用fallback解析器，可以通过定义SIMDJSON_IMPLEMENTATION_FALLBACK宏来实现。但需要注意的是，这会增加最终二进制文件的大小，而实际上可能永远不会被使用到。