Pavise v3.3.0.8 配置指南：从游戏识别到会话恢复

使用 Pavise 调整游戏资源时，最先要验证的不是帧率，而是调度链路：游戏有没有识别正确，配置有没有作用在正确对象上，退出后该恢复的项目有没有归还。链路成立后，再比较效果，才容易解释某次调整带来的变化。

本文按 3.3.0.8 的配置和日志组织一套首次检查顺序。Pavise 是 bdth 维护的免费开源 Windows 游戏资源管理工具，可管理后台资源优先级、逐游戏 CPU 范围、渲染亲和性和对局电源。各模块按保存的选择及本机支持条件执行。

系统要求为 Windows 10 2004（19041）及以上，依赖 .NET Framework 4.7.2 或更高版本，并以管理员权限运行。先确认这些条件，再处理功能是否可用的问题，避免把环境缺项误判为选项失效。

保存到固定目录。若使用完整 ZIP，随包文件一起解压；单独的 Pavise.exe 是另一种获取形式，不能认为它包含完整 ZIP 的全部附件。升级时先结束游戏、正常关闭旧版，再替换程序，避免让旧会话与新程序交叉工作。

内置更新入口为"关于 → 检查与更新"，更新保留个人数据。已有配置也会保留；要应用重新定义的预设，需要明确重新选择，不能用"更新成功"代替配置核对。

从底栏进入游戏库，添加实际游戏 EXE。登录器、启动器、内置网页和最终游戏进程可能不相同，调整的目标应是要运行的游戏本体。3.3.0.8 优化了鸣潮等游戏识别，减少内置网页误识别，但首次配置仍应查看概览中的实际识别状态。

再进入白名单，检查对局期间需要正常工作的程序。语音与直播工具不是游戏本体，却可能直接影响使用。竞技场景中，普通应用切到前台不会自动脱离治理，因此不要等到切屏后才想起补保护规则。

3.3.0.8 演示画面使用模拟游戏及读数，只用于定位概览、底栏和守护入口。

确认目标后再启用守护。先不开大量高级项目，可以把"识别---执行---退出"作为第一次验证的最小范围，后续出现问题更容易定位到具体配置组。

智能、竞技决定会话范围；关闭、正常、激进决定后台治理强度。这是两组不同选择，不能把竞技场景直接等同于激进档。

智能场景会按前台与负载调整治理范围，切出游戏释放后台治理，但对局电源和亲和性继续保留。竞技场景在整个对局期间保持治理，切出也不释放，普通软件变成前台不自动豁免。两者都保护游戏、白名单与必要依赖。

正常档降低符合条件的后台 CPU 等资源优先级，并启用效率模式。激进档额外限制 Windows 对这些后台线程的临时提优。说明范围时应保留"符合条件"：受保护对象与系统管理对象并不会都被强制处理。

如果切屏后的应用响应和预期不同，先核对场景与白名单；如果后台治理几乎没有变化，再核对档位、对象保护及实际负载。将两个问题分开排查，比不断切换整套预设更清楚。

进入对应游戏的深度调优，查看核心调度与渲染线程亲和性。逐游戏保存，意味着可以为不同游戏保留不同范围，而不是用全局绑核方案覆盖所有程序。

演示窗口展示核心调度、同族后台、ReBAR 和渲染线程亲和性等入口；不代表示例中的开关状态适合本机。

3.3.0.8 支持渲染自动、手动选核与物理核避让，并联动游戏核心范围。未开启核心调度时，手动选择显示全核心。选核和核心范围调整在下局生效，关闭渲染亲和性立即撤回。

排查"修改后没有变化"时，应先确认是否重新建立下一局会话。若在同一局连续改动多个范围，观察结果可能混入不同生效时点。把当前配置记下来，下一局再核对，会比仅看开关亮灭更有意义。

核心避让针对可管理线程和进程，系统中断与受保护进程仍受 Windows 管理。不要用一张核心选择图推导出"所有资源已独占"，也不要把某台机器上的核心编号直接套用到另一种 CPU 拓扑。

性能页区分对局生效与长期生效。大部分对局控制在游戏结束后恢复已记录的原值，长期项目按各自说明关闭或恢复，部分需要重启。缓存清理、文件删除不属于可逆的开关变更。

按"对局生效"和"长期生效"分组检查，避免用一次退局代替所有恢复操作。

"作者同款"和"极限配置"是批量设置功能的预设，智能、竞技是另一组选择。预设涉及 VBS、CPU 软件缓解等长期项目，会改变相应防护。首次配置应逐项看清含义与重启提示，不把整套预设作为通用前置步骤。

电源恢复还应考虑厂商控制。笔记本、台式机和支持名单中的掌机采用不同处理方式。3.3.0.8 遇到持续的厂商电源冲突会停止切换并恢复原计划；反复看见计划变化时，应检查是否还有厂商工具在同时管理。

动作日志用于查看压制、落核、清核与恢复的执行结果。诊断日志保留更细的技术信息，3.3.0.8 支持分别导出。定位问题时，先用动作日志确认哪一个阶段不符合预期，再结合诊断信息补充原因。

恢复失败有执行预算，达到上限会停止主动尝试、保留恢复记录。因此，自动恢复不是无限重试的保证。离开游戏后查看当前状态，遇到未完成项目保留该会话日志，不要只通过再次启动游戏把问题覆盖过去。

需要反馈时，写清 Pavise 版本、Windows 版本、CPU、显卡、游戏名称、相关设置与复现步骤，并说明最近是否更新系统、游戏或驱动。比起只贴一张占用率截图，这些信息更能缩小问题范围。

验证效果时固定游戏场景与画质，尽量保持后台负载一致，逐组比较卡顿与响应。不要并行运行其他会修改进程优先级或 CPU 亲和性的调度软件，避免设置互相覆盖。能把识别、配置、执行与恢复对应起来，后续性能判断才有可追溯的基础。