浏览器 JIT 的逐层降级

【踩坑实录】浏览器 JIT 的逐层降级

▍现象
文献管理工程（Gecko 内核）上机：进程早期崩溃，崩溃点在引擎的上下文创建——分配 JIT 可执行内存失败，引擎的内存分配器触发致命错误退出。日志指向明确：JIT 的可写代码段权限没到位。

▍定位过程
这是一个权限双闸问题（工程的二分实验记录很精彩）：JIT 可执行内存的权限在系统侧有两处开关——签名 Profile 的受限权限表（ACL）与应用配置的权限声明。工程做了对照实验：同一份库、同一份数据，两处都满足的进程正常运行；只满足 Profile 侧（配置声明缺失）的进程在早期上下文创建时分配失败崩溃。结论：双闸缺一不可——只办了 ACL 证书侧的手续、忘了应用配置里的显式声明，就是崩。

▍对策
双闸补齐（Profile 的 ACL 加应用配置的显式声明，缺哪个补哪个）；权限语义文档化（工程把二分实验的结论写进配置注释——下个维护者不用重考一遍）；降级链预案（真拿不到 JIT 权限的环境：引擎有解释执行模式，性能降级但功能完整——移动端低配设备的兜底档）。工程的后续演进还做了 JIT 的分包变体（按设备形态分发不同权限配置的包），把权限面与设备能力对齐。

▍根因抽象
JIT 类权限是典型的多点配置能力：证书、配置、运行时三层的任何一层缺失都表现为同一个崩溃。排查思路：从崩溃点反查是哪层没到位（而不是盲目重签重装）。

▍方法论沉淀
权限类问题的对照实验法（控制变量逐层补齐，哪层补齐后恢复就是哪层的锅）；权限双闸的检查清单进发布流程。

双闸实验的完整记录在文献管理工程实录，apps 板块 56 篇欢迎对照。