先把你这段长时间排查的关键信息“抽象成模型”，再回答你现在其实关心的两个问题：
这到底是什么机制在电池下把机器从睡眠里“弄死”的？
在 尽量不启用大休眠文件 的前提下，怎么把这个行为压到最低、至少搞清边界？
一、从你的记录看，本质就是“自适应休眠 + Modern Standby”在电池下发力
你自己整理的时间轴非常关键：
接电源模式：
典型事件链：
506 进入连接待机→507 退出待机→（必要时）42 睡眠/107 恢复基本不会出现 6008；睡一晚上基本没事。
电池模式（尤其是合盖）：
多次复现：睡眠后约 25 分钟～2 小时就 6008 意外关机；
日志里只看到：
先
506 进入连接待机 (原因 Lid 或 Idle Timeout)一段时间后直接出现
6008 意外关闭，然后下一次才6009 系统启动；中间没有
42/107，有时有172 断开/重新连接类似网络相关。
和微软“自适应休眠”文档完全对上号：
Modern Standby（新式待机）期间，Windows 会启用“自适应休眠 (Adaptive Hibernate)”：
通过 StandbyBudgetPercent / StandbyBudgetRefreshInterval / StandbyBudgetRefreshCount 这三组参数控制：
在某个刷新周期（默认 12 小时，OEM 可以改）内，电池允许下降多少百分比；
刷新多少次预算；
如果实际耗电超过预算，就触发休眠。
这些设置是 隐藏的电源设置，只在直流电（DC/电池）下生效，对交流电（AC）无效。
另外还有你提到的：
StandbyReserveTime/StandbyReserveGracePeriod各种“待机保留时间、待机重置百分比、预算宽限期”等 共同构成了一套电池下的安全网——长时间待机时，最终一定要把系统推进到休眠（S4）去，以防电池被“吊死”。
在 你关闭休眠的前提下：
当自适应休眠这套逻辑在电池下判定“该休眠了”时：
尝试进入 S4 会失败；
结果就变成 直接掉电关机 → 6008，
这就是你看到的“睡眠 1～2 小时就自动关机”的根本原因。
接电源时没有这套强制逻辑，这就是“插电睡眠没事、用电池睡眠会死”的核心差异。
二、你已经验证过：调 powercfg + 改参数，只能缓解，不能根治
你做过大量“科学实验”，可以归纳成几点结论：
单纯调传统参数（在此时间后休眠、无人参与睡眠超时、混合睡眠）：
改成“在此时间后休眠=0，从不”；
改成“无人参与睡眠超时 3600→120”；
关闭混合睡眠等； → 依旧：睡眠 1～2 小时关机。 说明：问题不在这套“经典电源计划”的可见参数上。
调自适应休眠相关（StandbyBudgetPercent/Interval/Count、ReserveTime 等）：
StandbyBudgetPercent 从 1% 改成 10% 后，确实有一段时间缓解（不再那么容易触发）；
待机保留时间 / 宽限期 / 非传感器超时等参数恢复默认或调大，也能改变“多少分钟后才死”的阈值；
但随着重装 AMD 芯片组 / 显卡驱动等，行为又变得不稳定（再次 1～2 小时内关机）。 → 说明：
确实是 Modern Standby + 自适应休眠 在起作用；
但具体触发时刻不仅跟这些 powercfg 里的值有关，还跟 实际耗电曲线、驱动、电池状态、固件逻辑 一起决定。
系统版本对比：Win11 Home 默认几乎没问题，Win10 LTSC 经多次更新后波动明显
同一套电源方案导入 Win11：睡眠正常保持；
Win10 LTSC 从 2025 以后（多次累积更新）开始睡眠变得不稳定；
肉眼可见：Win10 这条分支上，Modern Standby + 自适应休眠 + 某些 AMD 平台组合下的行为更“激进”或存在 bug。
综上： 你已经把 所有能从 powercfg 里“摸”的旋钮都摸了一遍，结果是：
能把“多少分钟后死”这个时间窗来回移动；
但 只要休眠功能整体是关闭的，在电池下长时间待机，最终还是会踩到那条“强制进入休眠（失败→关机）”路径。
三、给你一个更加“工程化”的结论
从你的数据 + 官方自适应休眠文档可以得出一个比较冷静的现实：
在这个支持 Modern Standby 的平台上， “电池 + 长时间睡眠 + 完全关闭休眠” 这个组合，本身就是不被微软设计为“必须保证不关机”的场景。
操作系统和 OEM 默认假设：
电池下长时间待机，最终一定要有机会进入休眠（S4） 把内存写盘、保护数据和电池；
自适应休眠（StandbyBudgetXxx、ReserveXxx）就是为这个建立的一套“兜底逻辑”， 而且只在电池下生效，对接电不管；
你把休眠整体关掉，相当于：
把“兜底缓冲层”拆了；
让系统在“应该跳 S4”的那一刻找不到落脚点，只能硬关机。
这也解释了：
接电睡眠没事：
自适应休眠的这些触发器对 AC 不起作用 / 不会走到强制休眠；
机器可以一直挂在 S0 待机里“装死”。
电池睡眠会关机：
只要待机时间足够长 & 耗电模式符合某个判定，就会被强制“进入休眠”；
但休眠被禁用 → 6008。
四、在“不想要大休眠文件”的前提下，你的选择边界
你现在的目标是：
保留：
Modern Standby（连接待机，接电 / 电池时都能用）；
尽量正常的睡眠体验；
又不想：
有几十 GB 的
hiberfil.sys占空间。
硬约束是：只要电池下允许长时间 S0 待机，系统就迟早会想办法去 S4。 在休眠禁用的前提下，这条路“本质上不安全”。
从工程角度看，你能做的就是在这些选项里取舍：
接受小一些的休眠文件，换稳定性（推荐但你之前排斥）
powercfg /hibernate onpowercfg /h /type fullpowercfg /h /size 40（最小 40% 内存；64GB RAM 大约 25GB）然后把：
自适应休眠参数调到合理值（你已经在做：StandbyBudgetPercent 不要太小；ReserveTime、GracePeriod 拉长一点）；
在此时间后休眠设成你能接受的时间窗口（例如 4～6 小时）。
这样：
即便自适应休眠在电池下判定“该休眠”，它也能正常进 S4，而不是 6008；
你夜里长时间合盖睡眠，也不会再丢桌面和数据。
保持关闭休眠，但接受“电池长时间待机是不可靠的”
接电合盖 → 正常睡眠 / Modern Standby，可以信任；
电池合盖：
只用于短时间休眠（几十分钟级），不要指望一夜不掉电；
或者干脆在电池下睡前手动关机；
这相当于人为规避那条“电池长时间待机→自适应休眠→失败→关机”的路径。
尝试从根上关掉 Modern Standby（退回经典 S3），但风险和难度都高
少数机器可以通过 BIOS 把 S0 Modern Standby 改回 S3；
或通过
PlatformAoAcOverride等注册表 hack（但在新系统上支持越来越差，而且容易被更新打回去）；如果真能把系统改到只支持 S3 睡眠：
那“自适应休眠 + Modern Standby”的这一坨逻辑就不再存在；
你可以像老机器一样，用传统“睡眠 + 休眠”逻辑，甚至关掉休眠只用 S3；
但这个操作依赖具体型号/BIOS，不是一条通用、无风险的建议。
五、结合你现有的排查结果，一个可执行的建议
在你现在这台 LTSC 机器上，要达到“电池 + 长时间睡眠 + 不自动关机”，现实可行的方案只有这两步：
重新启用休眠（哪怕只启一段时间做验证）
powercfg /hibernate on
powercfg /h /type full
powercfg /h /size 40把自适应休眠 & Standby 相关参数调整到“合理但不激进”的区间
StandbyBudgetPercent：建议 ≥5%，不要用 1% 这种极低值；StandbyBudgetRefreshInterval：不要缩到 1800/900，尽量接近默认的 12 小时；StandbyBudgetRefreshCount：维持默认 3–4 次；StandbyReserveTime：从 600 调到 1200 或更高；Standby Reserve Grace Period：至少保持默认 300 秒；Hibernate After(DC)：设成你能接受的时长，比如 4～8 小时。
然后用我们做的那两个脚本：
scan_power_schemes.py：确认这些参数值确实已经生效；generate_sleep_shutdown_report.ps1：每天早上看一下：夜里是否还出现孤立的
6008；是否已经变成“有 42/107 + 休眠相关事件（30/32/27/1 等）”。
如果在这个配置下，电池睡一晚都只是正常休眠/唤醒，而不再有 6008，你就拿到了一个“稳定解”；到时候你可以再评估：这 20 多 GB 的空间是否值得。
否则，在坚持完全关闭休眠的前提下，结论就是你自己已经验证出来的那句：
电池睡眠 1–2 小时自动关机，是这个平台上的“正常坏行为”，不是你某一项配置单点错误造成的。 要么接受它，要么接受休眠文件。