寄存器被意外修改导致程序异常
在调试一段x86汇编代码时，发现函数返回后主程序突然崩溃。检查堆栈平衡没有问题，但数据明显错乱。最终定位到是某个寄存器值被修改了。这种情况很典型——你调用了一个子程序，它改动了EAX，而你恰好依赖EAX保存关键地址。
比如有这样一段代码：
mov eax, buffer_addr
call process_data
; 此时eax已不再是buffer_addr，但后续代码仍用它寻址
mov byte ptr [eax], 0如果process_data内部没保护EAX，或者你自己忘了恢复，就会出问题。解决方法是在调用前压栈保存：
push eax
call process_data
pop eax函数传参时寄存器使用混乱
在32位系统中，常用EAX、ECX、EDX传递参数，但不同调用约定规则不同。cdecl通常用栈传参，而fastcall会优先用ECX和EDX。如果你混用了约定，寄存器里的值就对不上。
举个例子，你写了个fastcall函数，却按cdecl方式使用ECX传参：
mov ecx, param1 ; 错误：fastcall第一个参数应放ECX，但你可能多此一举
mov edx, param2
call func结果func本身也会把第一个参数从ECX读走，造成重复或错位。正确的做法是确认调用规范，并严格遵循寄存器职责。
标志寄存器状态被干扰
有时候条件跳转不按预期执行，比如JE没跳，实际是因为前面的指令影响了ZF，而你没意识到。像MOV指令不影响标志位，但ADD、CMP会。
常见错误：
cmp eax, ebx
mov ecx, edx ; 这条指令不影响标志位，安全
add eax, 1 ; 这条会影响，如果后面还依赖之前的ZF就糟了
je target ; 可能不会跳，即使之前cmp相等解决办法是在关键判断前确保标志位未被破坏，必要时提前保存EFLAGS。
寄存器复用引发逻辑错误
为了节省寄存器，有人喜欢反复使用同一个寄存器。比如用EAX既当计数器又当临时缓冲地址。这种“一材多用”在小段代码里看似高效，但在复杂流程中极易出错。
比如循环中用EAX做索引，中途插入一段操作又改了EAX，循环就失控了：
mov eax, 0
loop_start:
cmp eax, 10
jge loop_end
; 中间某处不小心改变了eax
mov eax, some_value ; 循环变量被覆盖
inc eax
jmp loop_start
loop_end:这时候循环根本停不下来。建议分工明确，计数器用ECX，地址用EDI或EBX，减少冲突。
调试时如何观察寄存器状态
用GDB或x64dbg这类工具时，别只盯着代码窗口。打开寄存器视图，单步执行时留意每个寄存器的变化。特别是调用函数前后，重点看EAX、ECX、EDX、ESP、EIP是否如预期。
比如发现ESP不对，可能是堆栈没对齐，或是RET时弹出了错误值。这时候回溯最近一次PUSH/POP操作，往往能快速定位问题。