设置Image的src与绑定onload、addEventListener的先后顺序是否影响生效？

核心结论 #

你遇到的现象是老旧浏览器实现差异、现代浏览器统一事件循环规范共同作用的结果，「必须先绑定事件监听再设置src」的认知并未完全过时，只是触发失效的场景变窄了。

为什么同步延迟无法复现失效 #

JavaScript的事件循环规则明确要求：所有同步代码会在主线程执行栈中按顺序执行，包括图片load回调在内的所有异步任务，必须等当前执行栈完全清空后才会被调度执行。
你测试用的10亿次循环是同步阻塞代码，哪怕执行数秒，主线程都会被它完全占用，这时候就算图片已经加载完成，load事件的回调也只会暂存在异步任务队列等待，不会在循环结束、监听绑定完成前执行。只要绑定监听的代码和src赋值处在同一个同步执行上下文，不管中间加多少同步延迟，都一定能触发回调。
只有当绑定监听的逻辑本身是异步的（比如你测试用的setTimeout），才有可能出现load事件先触发完成，之后才绑定监听的情况，自然收不到回调。

「先绑监听再设src」的来源 #

这个结论是针对老旧浏览器（IE6/7、本世纪初的早期Chrome/Firefox版本）的实现得出的最佳实践。
旧浏览器没有严格遵循事件循环规范：如果要加载的图片已经在本地缓存中，设置src属性时会同步触发load事件，也就是在src赋值语句执行过程中就直接调用当前绑定的onload函数，执行完成后才会跑下一行代码。这时候如果在src赋值之后才绑定监听，事件已经触发完成，自然不会再执行回调。

现代浏览器的变化 #

现在所有主流浏览器都统一了事件循环实现，哪怕图片已经在缓存里，load事件的回调也会被推到异步任务队列，等待当前同步执行栈清空后再执行。所以只要监听绑定代码和src赋值在同一个同步流程里，不管顺序先后都能收到事件。
但依然推荐遵循先绑定监听再设src的最佳实践，原因有两点：

• 若后续代码重构，把绑定监听的逻辑挪到异步上下文（比如await接口返回后再绑定），就有概率出现监听丢失的问题
• 若需要兼容极端老旧的运行环境，旧浏览器的实现问题依然存在

内容的提问来源于stack exchange，提问作者Greg Sadetsky