游戏里"血量"到底藏在哪，这件事我交了两次学费
第一次写内存辅助脚本，目标很单纯：自动喝药。要实现它，我得先实时知道血量在哪、是多少。听起来理所当然，真去挖才发现，这玩意儿坑比我想的深。我前后交了两次学费，才把「找数据」这件事摸到门道。
第一回，我用精确值扫描，游戏里血量 1200，我就搜 1200。结果搜出来两万多个地址——同名变量、无关数值、缓存，全混在一起。喝口药变成 1180，再筛「变成 1180 的」，还剩三百多个。继续掉、继续筛，最后剩 7 个，挨个改值试，才撞中真正那个。运气好，运气不好筛到最后一个才中。这法子纯靠莽，效率低得离谱。
后来学会了用"变化"代替"猜值"
正确的思路不是去猜当前值，而是利用「它一定在变」。先用「未知初始值」扫一遍全部内存，然后回游戏让血量变动，再用「变动的数值 / 未变动的数值」反复筛。逻辑是：每一轮只保留「跟上一次比，确实变了（或没变）」的地址。三四轮下来，候选从百万级掉到个位数。这比精确值盲搜聪明太多，因为它不依赖你事先知道数值，只依赖「值在变」这个事实。
# 本质逻辑（CE 是 GUI，这是背后在做的）
cands = all_addrs
for each_round:
action() # 让血量变动/不变
cands = [a for a in cands if changed(a) == expect]
但第二回学费来得更快：我好不容易定位的地址，重启游戏后整个失效，脚本读到的全是乱值。我一度怀疑自己改错了，重找一遍又对了，再重启又废。循环了三次才想通——地址空间随机化（ASLR）让进程每次加载基址都不同，我找到的是「绝对地址」，而它每次都飘。
真正要找的是"基址 + 偏移"
内存里实际是链式存放的：某个固定模块基址，加上一串偏移，最终指向血量。重启后基址变了，但「基址相对模块的偏移 + 后续偏移链」是不变的。所以正确做法是用指针扫描（pointer scan）：从找到的血量地址往上追，找出「谁指向它」，一层层追到一块每次重启都固定的基址。得到这条偏移链后，下次重启用同一套链重新算，就能再定位。
一个实用提醒：很多游戏把血量放在「对象结构体」里，基址往往要从角色对象指针追起，偏移链可能两三层。链越长越脆弱（任意一层指错就全错），所以扫指针时要给足层级深度，又别深到扫出一堆噪音。
找数据这件事，我现在的体会是：它像侦探多过像程序员。你手里只有「它在变」「它大概是什么类型」这种模糊线索，要靠一轮轮假设和排除去逼近真相。蛮力能碰巧成功一次，但只有理解了「为什么地址会飘、为什么要用偏移链」，你才能在下个完全不一样的程序里，照样把它揪出来。
