js代码格式化原理：从词法到输出的完整流程

准备工作：理解格式化器的输入与输出

在动手之前，先明确格式化器处理的对象是源代码文本，输出也是源代码文本，中间不执行代码。你需要准备：

• 一份待处理的 JavaScript 源文件，建议先备份或纳入版本控制，便于对比格式化前后的差异。
• 一个可运行的格式化工具，例如 Prettier、ESLint 的 --fix 模式或编辑器内置的格式化功能。
• 一份配置文件（如 .prettierrc、.eslintrc），用于声明缩进宽度、引号类型、分号策略等偏好。

关键认知：格式化器不会改变代码的运行时行为，它只调整空白、换行和部分标点。理解这一点，你就能放心地把格式化纳入日常流程，而不必担心逻辑被改写。

分步操作：从读取到写回的完整链路

第一步：读取源文本并做词法分析。 格式化器先把字符流切分成 token，例如关键字、标识符、运算符、字符串字面量和注释。这一步会忽略空白和换行，因为它们不是语法的一部分。

第二步：构建抽象语法树（AST）。 解析器根据 token 序列生成树形结构，节点表示语句、表达式、函数声明等。AST 保留了代码的语法关系，但不保留原始空白信息。

第三步：应用格式化规则。 遍历 AST，按照配置决定每个节点的输出形式：缩进层级、是否换行、运算符两侧空格、对象字面量的尾随逗号等。规则通常以打印函数的形式实现，每个节点类型对应一段输出逻辑。

第四步：生成输出文本。 打印过程把 AST 重新序列化为字符串，同时插入换行和缩进。注释的位置需要额外处理，因为注释不属于 AST 的标准节点，多数工具会将其挂载到相邻节点上。

第五步：写回文件或返回结果。 将生成的文本与原始文本对比，若有差异则写回。在编辑器中，这一步通常由保存动作触发；在命令行中，则由显式命令触发。

常见错误与排查

格式化后代码行为改变。 这通常不是格式化器本身的问题，而是源文件存在语法歧义或自动分号插入（ASI）的边界情况。排查方法：对比格式化前后的 AST，确认节点结构是否一致。

注释丢失或错位。 当注释出现在不常见的位置，例如两个表达式之间或行尾，打印器可能无法正确挂载。可以尝试调整注释位置，或检查工具版本是否支持该场景。

配置不生效。 常见原因是配置文件未被读取，例如文件位置不对、存在多个配置源冲突，或编辑器使用了内置格式化器而非项目配置。排查时先确认工具实际加载的配置路径。

输出风格与预期不符。 不同工具对同一规则的实现细节可能有差异，例如对象换行阈值。此时应查阅该工具的文档，而不是反复修改源码。

进阶技巧：让格式化更贴合项目

• 利用忽略注释。 在特定代码块前后添加格式化忽略标记，可以保留手写对齐的表格或特殊排版。
• 分阶段格式化。 对大型遗留项目，先格式化新增文件，再逐步处理旧文件，避免一次性产生大量差异。
• 结合 lint 规则。 把格式化交给专用工具，把逻辑检查交给 lint，两者职责分离，配置更清晰。
• 自定义打印器。 如果项目有特殊语法扩展，可以基于现有解析器编写插件，扩展节点类型的输出逻辑。
• 在 CI 中校验。 将格式化检查加入持续集成，确保提交的代码风格一致，减少合并冲突。

常见问题