遇到 EAccessViolation 怎么办？90% 的人都是因为这个错误！

这两天，我被一个破问题给整崩溃了。一个项目，我明明感觉自己写得像模像样，结果冷不丁地，它就给我蹦出来一个EAccessViolation的错误，而且还不是每次都出现，完全是随机的，把我搞得心头火蹭地一下就上来了。

第一回合：从头到尾，先抓瞎！

你懂那种感觉吗？程序一出错，我第一个动作就是打开日志，盯着它崩掉的那几行代码看，希望能看出个花儿来。我当时想，这可是个访问冲突，肯定是最近引入的某个DLL，或者我改了哪个对象释放的顺序，把内存给弄混乱了。我根本没往别处想！

我立马动手翻查：

• 我详细检查了所有新加入的第三方库的API调用，看有没有什么不安全的指针操作。
• 然后我又去翻阅了所有跟线程同步有关的代码块，怀疑是不是哪个资源在多线程里面被同时访问了。
• 我甚至动用了内存分析工具，去查找是不是有内存泄漏或者野指针在作怪。

我前前后后忙活了三个多小时，查了一堆高大上的技术点，结果？ 屁都没查出来！这错误就像个鬼影一样，你越想抓住它，它跑得越快，搞得我差点想直接把那块业务功能推倒重写。

第二回合：冷静下来，才发现是低级错误！

后来我实在顶不住了，去茶水间泡了杯浓茶，强迫自己冷静下来。我坐在那里，脑子里突然回想起以前一个老前辈跟我说的一句话：“越是看起来复杂的错误，它就越可能是个低级错误。”

我决定换个思路。不看那堆栈信息后半段复杂的调用链了，我直接把光标定位到EAccessViolation错误发生的前一步，也就是那个对象被访问的代码块。然后，我开始从头审视最原始的逻辑。

这一看，我的老天爷！ 我差点当场给自己两巴掌！

我发现了什么？

• 我在某个逻辑分支里，先调用了一个方法去尝试初始化一个核心对象，比如一个数据库连接、一个配置读取器什么的。
• 然后，后面的代码逻辑根本就没有判断那个对象是否真的初始化成功！它直接就去调用那个对象的方法了。
• 在某些网络不好或者配置读取失败的特定场景下，那个对象根本没被创建，它还是个空指针（或者没被赋值）！
• 我还傻乎乎地让程序去访问这个“空”对象里的方法和数据！这不就是典型的空访问嘛

最终解决：简单到想骂人！

这个EAccessViolation说白了，百分之九十都是对象没创建，你非要用它导致的。就像标题说的，90%的人都是栽在这个极其简单的错误上，包括我自己！

我的解决办法简单到让你想骂人：我马上动手，在那段访问代码前面，加了一行判断。

我所做的，不过就是加上了一个最基本的判断。

如果（那个关键对象 != 空） { 才能去执行后续操作 }

就这么一句，所有随机的、恼人的EAccessViolation瞬间都消失了，程序跑得比我刚来时候都稳定。这事儿给我一个狠狠的教训：别老盯着高大上的架构和复杂的内存问题，先看看你最基础的对象有没有成功出生、有没有成功被赋值。 浪费了我整整一个下午的生命去查野指针，结果是查了个寂寞！今天分享出来，就是让你们少走我这个愚蠢的弯路，遇到这种错，先看是不是空访问！