一、精确搜索与模糊搜索：先判断数值是哪种
绝大多数「搜不到」的抱怨，源头都在这一步没有分类。内存里的数值可以粗分成两类：界面直接显示、并且能被工具原样读到的明文值，以及经过运算或加密后才写入内存的变动值。前者用精确搜索，后者用模糊搜索，两者不要混着用。
精确搜索的操作链条可以压缩成四个动作：输入当前值 → 让数值在游戏里真实变化一次 → 输入新值并选择改善 → 重复收敛。这里最容易做错的是第二步：不少人只是切换了界面，并没有让数值真正增减，结果第二次搜索把正确的候选一并过滤掉了。判断标准很简单——数值必须发生可被游戏逻辑承认的变动，例如消费掉一部分金币、升一级、拾取一个道具。
模糊搜索的入口一般写作「未知初始值」或「模糊搜索」。它不要求你输入具体数字，而是让你在数值变化后回答「变大了 / 变小了 / 没有变化」。血条、进度槽、隐藏的好感度或疲劳值都属于这一类。经验上，第一次模糊搜索会留下数量庞大的候选，之后每一轮筛选大致能去掉七到九成，四到六轮即可锁定区间。
一个容易忽略的细节：模糊搜索期间不要频繁切换游戏画面或让数值同时受多个机制影响。如果一个数值在被敌人打掉的同时又自动回复，你上报的「变大 / 变小」就可能与真实趋势相反，搜索树会直接走偏。
二、联合搜索：让分号替你做一次筛除
联合搜索的写法是在搜索框里用分号把多个数值串起来，例如 555;222。它解决的是一个很实际的问题：当你要找的数值本身没有辨识度（比如攻击力 37 这种随处可见的数字），单独搜索会得到一大片无关地址，而多个关联数值连续出现在内存中的概率要低得多。
它最典型的用途是角色面板。攻击、防御、暴击、抗性这类属性经常在内存里成组排列，把其中两到三个当前值一起搜，结果数量往往能直接下降一到两个数量级。找到之后如果只想改一项，回到搜索框单独输入那一个数值并执行改善，就能把其余数值从结果中剔除，实现「只动一个、不碰其他」。
联合搜索还有一层进阶用法是配合顺序限定，用来描述「这几个值之间的间隔是固定的」这种结构。它需要你对目标游戏的内存布局有基本判断，属于熟练之后再去尝试的技巧，新手阶段不必强求。相关原理与内存区域的关系，可参考 兼容说明页的内存范围章节。
三、加密值识别：给偏移与异或留一条通道
有些游戏的数值不是原样存放的。界面显示 1000，内存里可能是 1000 + 256、1000 * 2，或者与某个固定数异或之后的结果。这类数据用精确搜索几乎必然空手而归，但它并非无法处理。
正常路径有两条。第一条是把「此值被加密」勾上，让工具按常见的偏移与异或组合自动尝试匹配；这条路径对结构简单、偏移固定的加密最有效。第二条是绕开加密本身，用模糊搜索按趋势逼近——它不需要知道真实存储值，只依赖数值的变化方向。当第一种方式屡次失败时，第二种通常更稳。
注意：自动匹配加密有尝试成本。面对明显由服务器下发的数值（例如联网对战里的伤害结算数），继续尝试加密搜索基本没有意义，请直接参考 安全提示 判断该场景是否值得投入。
四、冻结锁定：解决「改完就回弹」
找到地址、写入新值，回到游戏却发现数值又被覆盖回去——这是新手阶段最常见的挫败点。原因通常是游戏在结算、切换场景或定时刷新时会重新向这段内存写入数据。冻结锁定的作用就是在写入之后持续维持该地址的值，让游戏的覆盖动作落空。
使用时有两个判断点。其一，冻结不是万能的：如果数值实际来自服务器同步，本地冻结只能维持界面表现，功能层面依然按服务端数据判定。其二，冻结数量不宜过多：同时冻结几十个地址会带来明显的持续开销，也可能增加被检测的概率。建议只对一到三个真正需要稳定的关键数值开启。
五、变速调节：它的边界比想象中窄
变速的入口通常需要长按悬浮图标调出。它的价值集中在两类场景：一是跳过单机游戏里漫长的建造、研究、等待计时；二是在动作或节奏类玩法里放慢速度，用来观察判定帧。
但它有几个明确的边界。变速会改变游戏主循环的时间步长，因此对依赖计时同步的玩法影响很大，联机场景下还会直接造成与服务端的时间不同步，触发断线或异常检测。另外，加速倍率越高，掉帧与卡顿越明显，部分游戏在高速下会出现物理穿模。使用建议是从较低的倍率开始，确认画面稳定后再逐步上调。
六、脚本执行：把重复流程固化下来
当同一套查找与修改逻辑需要反复执行时，脚本就是更省事的选择。gg修改器 内置的脚本入口支持加载 Lua 脚本，脚本里可以声明要搜索的内存范围、目标数据类型、结果数量上限，以及逐条或批量改写的方式。
对普通玩家来说，脚本最实用的地方是跨地图、跨场景复用。手工搜索每次都要重新走一遍「搜当前值—让数值变化—改善筛选」的流程，而脚本可以把「搜索、筛选、写回、冻结」打包成一次执行。需要提醒的是，来源不明的脚本可能包含与你预期不符的额外操作，运行前建议先读一遍脚本内容再执行。脚本的具体入口位置与权限要求，可对照 上手指南的虚拟空间章节 一并确认。
七、内存范围怎么挑：范围越准，结果越少
搜索范围决定了工具要在多大的内存空间里做匹配。选得太大，结果里混入大量无关地址；选得太小，可能直接漏掉目标。实测下来，按以下顺序收窄通常最省时间。
| 范围代号 | 含义 | 是否建议首选 | 说明 |
|---|---|---|---|
Jh | Java 堆 | 视引擎而定 | Java 层 UI 与逻辑数据常驻于此，部分 Unity 之外的引擎会命中。 |
Ca | C++ 分配区 | 推荐 | 应用自身申请的堆内存，绝大多数游戏运行时数据落在这里，优先尝试。 |
Cb | C++ 静态区 | 推荐 | 全局变量与固定配置，数值稳定、不易随场景变化，命中后较可靠。 |
Cd | C++ 数据段 | 备选 | 初始化后的全局数据，部分老游戏的资源数值在此。 |
A | 匿名映射 | 备选 | 引擎自行映射的内存，某些自研引擎会用到。 |
S | 栈 | 一般不选 | 临时变量，生命周期极短，修改后基本无法维持。 |
Xs | 代码段 | 不建议 | 存放可执行指令，写入风险高，容易直接导致崩溃。 |
实践中的顺序是：先用 Ca 与 Cb 组合，搜不到再逐步加入 Jh 与 A。全程保持 Xs 不被勾选，可以显著减少闪退概率。
八、数据类型对照：长度不匹配就不会命中
搜索类型选错的典型症状是「搜索结果恒为空」，而不是「改错了值」。因为长度不匹配时，工具按错误宽度去比对字节，自然不会命中。
| 类型 | 字节宽度 | 典型场景 | 常见误区 |
|---|---|---|---|
Dword | 32 位整数 | 金币、钻石、等级、道具数量、体力 | 最通用，但遇到带小数的属性会完全搜不到。 |
Float | 32 位浮点 | 攻击力、百分比血量、抽卡概率、技能系数 | 界面显示整数、内存实为 100.0 时才需要它。 |
Double | 64 位浮点 | 坐标、重量、高精度伤害 | 用 Float 搜会因精度丢失而失败。 |
Word | 16 位整数 | 老游戏的 buff 层数、状态标记 | 新游戏基本不再使用。 |
Byte | 8 位整数 | 开关类状态、布尔标记 | 取值上限低，改大数会被截断。 |
Qword | 64 位整数 | 超大面额资源、时间戳 | 改小值时可被 Dword 命中，容易误判。 |
Auto | 自动匹配 | 不确定类型时兜底 | 结果数量翻倍，仅在明确失败后使用。 |
推荐流程：先按最可能的类型精确搜索；连续两次为空时，切到 Auto 或改用模糊搜索；确认数值确实存在但两种方式都失败，再去检查内存范围是否需要扩大，或参考 疑难排查页 的排查顺序逐项排除。
小结
这六条路径并不需要一次全部掌握。更稳妥的推进顺序是：先把精确搜索与改善流程练熟，再补上模糊搜索；等你能稳定锁定地址之后，再学联合搜索与冻结；脚本与变速放在最后。真正决定成败的往往不是功能多少，而是你在「搜不到」的那一刻，是否知道下一步该检查什么。这一部分已单独整理成 常见问题与故障排查手册，建议与本文对照阅读。