这个问题问得特别好——我刚接触async/await的时候也纠结过类似的内存可见性问题，咱们一步步拆解清楚：

先给明确结论：你的示例代码是安全的，async/await确实会隐式保证内存可见性 #

不管是你最开始那个Task.Yield()切换线程的简单例子，还是后来模拟请求后分线程修改数组的代码，都是正确且不会出现内存可见性问题的。核心原因有两个：一是async/await的实现本身就带有必要的内存屏障；二是你的代码是严格串行执行的，没有并行的读写操作。

为什么你复现不了“问题”？不是运气，是有隐式的内存屏障在起作用 #

你一开始担心跨线程修改无同步会触发缓存不一致，但在.NET的async/await机制里，await关键字背后藏着不少你看不到的内存同步逻辑：

1. await完成时会插入内存屏障：当你await一个Task（包括Task.Yield()返回的Task）时，Task的完成通知逻辑会自动插入内存屏障，确保在await之前的所有写入操作，对恢复执行的线程来说是完全可见的——简单说就是，CPU缓存不会把之前的写入“隐藏”，后续执行的线程一定能读到最新的值。
2. 状态机的隐式同步：async方法会被编译器转换成状态机，状态机的状态字段在不同线程间传递时，是带有内存可见性保证的。状态切换的过程中，.NET会确保状态的更新对所有线程可见，这也间接保证了你在状态机中对数组的写入，能被后续执行的线程看到。

什么时候这种代码会出问题？并行读写才是真正的风险点 #

你的示例代码是串行执行的：前半部分的写入完全完成后，才会触发await；等await完成后，再执行后半部分的写入。整个过程没有多个线程同时读写共享数组的情况，所以不存在数据竞争。

但如果出现以下场景，你就必须加显式同步（比如lock、Interlocked操作，或者使用线程安全的集合）：

• 在await的过程中，有其他线程同时修改这个共享数组
• 多个async方法同时操作同一个共享内存，且存在并行的读写行为

再澄清一个误区：跨线程访问≠数据竞争 #

你一开始以为“跨线程修改无同步是非法的”，这个说法并不准确：

• 真正的数据竞争是指多个线程同时访问同一个内存位置，且至少有一个是写入操作——这才是会导致未定义行为的根源
• 而你的例子是串行的跨线程访问：一个线程写完，另一个线程再操作，中间没有并行。只要保证内存可见性（而async/await已经帮你做了这件事），这种代码就是完全合法的。

最后给你的代码拍板 #

你写的这段代码：

async Task DoRequestAndStoreResult(int[] data)
{
    data[0] = 42; // 第一个线程写入
    await Task.Yield(); // 模拟实际异步操作，触发线程切换
    data[1] = 42; // 第二个线程写入
}

var result = new int[2];
await DoRequestAndStoreResult(result);
// 读取并处理结果

是完全正确的，不会因为内存可见性问题出bug。不需要额外加同步锁，因为async/await的机制已经保证了所有写入操作对后续读取的线程可见。