先想清楚：为什么现在要审计
关于pg模拟器，流传最广的一句话是“装上就能用”。这句话本身并不完全错，但它靠不住的地方在于：它把“能启动”当成了“可用”，又把“可用”当成了“可交付”。很多问题不是出在工具身上，而是出在动手之前没人问过一句——我到底要它跑在什么条件下？
所以这篇不是采购清单，也不是安装教程，而是一份可以对着自己当前环境逐条打勾的审计清单。审计的目的不是证明pg模拟器行不行，而是先纠正一个误区：默认状态不等于适配状态。 pg模拟器实用指南
审计范围：把“能跑”拆成可观察项
审计范围要收窄，否则会变成泛泛而谈。建议只覆盖三类可观察项：环境是否满足、配置是否被显式确认、出问题时是否能退回去。凡是无法观察、无法复现、无法描述的现象，先不列入本次审计。
- 能描述：用一句话说清“什么条件下、做什么操作、看到什么结果”。
- 能复现：同样的条件再走一遍，结果大致一致。
- 能回退：出现异常时，有明确的停止点和恢复动作。
第一组清单：环境与依赖
这一组最容易被跳过，因为大多数人默认“环境差不多就行”。其实环境差异往往是后续所有误判的源头。
- 运行平台与版本是否与手上资料描述的一致，而不是“看起来像”。
- 依赖项是否齐全，缺哪一项、由谁补，是否写下来。
- 磁盘与内存余量是否留出余量，而不是刚好卡在临界值。
- 网络条件是否稳定，是否需要离线准备。
- 是否存在多个版本共存，切换方式是否明确。
第二组清单：配置与默认值
默认值不是错，错在把默认值当成结论。审计时要区分“我确认过”和“我没动过”。
- 每一项被改动的配置，是否记录了改动原因。
- 未被改动的配置，是否确认过它适用于当前场景。
- 配置之间是否存在互相影响的项，改一个是否牵动另一个。
- 配置是否可导出、可备份、可对比。
- 是否存在“别人给的配置”直接套用而未核对的情况。
第三组清单：信号与回滚
这一组决定的是出问题时的代价。很多人把注意力全放在“怎么跑起来”，却忽略了“怎么停下来”。
- 是否知道正常状态下的信号表现，而不是只认得异常。
- 异常出现时，第一步是记录还是立刻重试，是否事先约定。
- 是否有明确的回滚点，回滚后环境是否回到已知状态。
- 回滚动作是否被验证过，而不是只写在文档里。
- 问题记录是否包含时间、操作、现象三要素。
危险信号：出现这些就先停下来
以下情况不一定代表pg模拟器本身有问题，但它们说明当前状态不适合继续推进。遇到时先停，比继续试更省时间。
- 同一个现象每次描述都不一样，无法复现。
- 依赖项来源不明，或版本信息缺失。
- 配置改动没有记录，只能靠回忆。
- 没有回滚点，或回滚后状态不可预期。
- 把“别人说可以”当作唯一依据。
整改顺序：从高到低的处理路径
整改不必一次做完，但要按代价排序。先处理影响面大、恢复成本高的项，再处理局部项。
- 先补齐可观察性：把现象写清楚，能复现再谈其他。
- 再固定环境与依赖：让每次运行的前提一致。
- 然后显式确认配置：把“默认”改成“已确认”。
- 最后完善回滚与记录：让异常有退路、有痕迹。
做完这一轮，你会发现“装上就能用”这个说法并不完全错，它只是省略了前提。pg模拟器实用指南里真正有价值的部分，往往不是某个技巧，而是这些看起来琐碎的核对项。审计一次，比反复试错更接近可用。