本资料介绍 Apex Language Server 的数据架构，主要面向类型解析、工作进程通信与资源加载相关开发。
硬性规则：语言特性不得用正则或文本启发式扫描原始 Apex 源码来推断符号、声明、类型、引用、作用域、成员、补全候选、定义或依赖名。语义结果必须来自 Apex 词法/语法分析器、语法树遍历、符号表、已解析引用/xref 数据或先前稳定的语义快照。原始文本仅可传给解析器及用于文档传输、位置/范围计算。语义状态不完整或过期时应等待、重试或返回不完整结果，不得凭空构造。
Apex 类型有三个来源：工作区（用户编写的 .cls、.trigger、.apex，由 data owner worker 经 didOpen/didChange/didSave 管理，按需编译并注册到符号图）；Faux SObject 类（表示 SObject 字段的文件，由外部进程按用户请求生成，放在工作区 .sfdx/tools/ 下，以与客户代码相同的文档操作呈现，不属于标准库）；标准 Apex 库 stdlib（System.String、Database.QueryLocator、ConnectApi.* 等，由 resource loader worker 独占，背后是 apex-parser-ast/resources/ 下三个只读预编译产物：apex-type-registry.pb.gz、apex-stdlib.pb.gz、StandardApexLibrary.zip，所有访问必须经 resource loader worker）。
工作进程拓扑：协调器（主线程）下辖 data owner worker（拥有工作区与 faux SObject 符号表）、2 个以上 enrichment worker（处理 hover、definition、diagnostics）、resource loader worker（拥有只读标准库）。data owner 是客户代码与 faux SObject 符号的唯一真源，接收文档生命周期事件，经 QuerySymbolSubset 向 enrichment worker 提供符号，并接受其回写。enrichment worker 并行处理 LSP 请求，经远程 ResourceLoaderService 访问 stdlib，本地无 protobuf 缓存、stdlib ZIP 或 GlobalTypeRegistry，仅有同步命名空间缓存。
GlobalTypeRegistry 定义于 apex-parser-ast/src/services/GlobalTypeRegistryService.ts，是进程内可变类型索引，跟踪三个来源的类型，提供 O(1) 跨文件解析；它是模块级单例，协调器进程有 stdlib 与用户类型，enrichment worker 中为空。修改 apex-parser-ast/src/symbols/ops/ 下解析代码时需注意其同时运行于协调器与 enrichment worker。
数据归属边界：协调器只做路由与消息传递，不做数据转换；data owner 负责符号图变更、合并与回写协调；enrichment worker 负责请求结果转换；resource loader 负责 stdlib 访问与重塑。LSP 请求路由定义于 apex-ls/src/server/WorkerCoordinator.ts：文档生命周期走 dataOwner，hover/definition/diagnostics 走 enrichmentPool 并回写，completion、references 等仍为 coordinatorOnly。
工作进程继承主进程的 profiling、debug 与堆大小标志，经 WorkerExecArgvBuilder 处理；工作进程命名 apex-worker-<role>，stderr 按角色标记转发。工作进程内只有 Effect 日志（在替换的 workerLogger 层下）与 emitWorkerLog 能到达协调器输出通道，异步处理器中的 getLogger 或临时 Effect.runPromise 日志不可达，诊断建议用 emitWorkerLog。关键路径包括 worker.platform.ts、WorkerCoordinator.ts、WorkerExecArgvBuilder.ts、CoordinatorAssistanceMediator.ts、symbols/ops/、GlobalTypeRegistryService.ts、resourceLoader.ts、WorkerBackendBootstrap.ts。