Parallel.ForEach 不保证执行顺序且不提供线程安全，而 foreach 严格保序；需用并发集合或异步任务队列替代共享变量操作，小数据量或IO密集场景不宜使用。
Parallel.ForEach 会乱序，foreach 一定按顺序
这是最直观、也最容易踩坑的区别。如果你写
测试，
输出永远是 1→2→3→4；而
可能输出 3→1→4→2，甚至每次运行都不一样。
原因：多个线程并行执行，谁先完成谁先输出，没有调度保证
后果：如果逻辑依赖顺序（比如累加到同一个变量、写入文件需严格编号），直接用
会出错
补救方式：不推荐“强行排序”，而是改用
+
异步任务
队列，或用
（但依然不保序）
线程安全不是 Parallel.ForEach 给的，是你自己要写的
本身是线程安全的——它不会崩，但它不管你的代码安不安全。你往里塞一个
，大概率会抛
或
数据丢失
。
常见错误现象：
或结果数量少于输入项数
正确做法：用线程安全集合，比如
、
，或加
（但锁太重会抵消并行收益）
特别注意：
是单线程的，天然没这问题，但它也不是
的替代品（类型受限、不支持异步）
性能不是“用了就快”，要看任务类型和数据量
小数据（比如 Parallel.ForEach 往往比
慢——线程创建、调度、同步开销压过了计算收益。
C函数速查手册（CHM版）
C函数速查手册（CHM版）
下载
适合加速的场景：
类型任务（CPU 密集，单次 > 10ms），数据量 ≥ 数千
不适合的场景：IO 密集（如逐个 HTTP 调用）、短循环（
.NET 6+ 推荐用
处理异步 IO，它比手动
更可控（可设最大并发数、支持
）
foreach + await 才是多数人真正该用的组合
别被“并行”二字带偏。90% 的业务逻辑需要顺序、可预测、易调试。比如“依次上传文件并记录日志”“按顺序更新数据库字段”，这时
配合
是最稳妥的选择。
它不抢资源、不争锁、异常堆栈清晰、断点好下
真要并发发请求？优先考虑
或上面提到的
，而不是硬套
+
记住：
是危险写法——编译器会转成
，异常无法捕获，千万别用
真正难的不是选哪个 API，而是判断“这个任务到底能不能并行”。顺序、共享状态、资源瓶颈、异常传播路径——这些比语法细节重要得多。
Console.WriteLine(item)foreachParallel.ForEachParallel.ForEachforeachAsParallel().ForAll()Parallel.ForEachsharedList.Add(item)ArgumentExceptionCollection was modified; enumeration operation may not execute.ConcurrentBagConcurrentQueuelockList.ForEach Parallel.ForEachforeachProcessHeavy(item)Parallel.ForEachAsyncTask.WhenAllCancellationTokenawait Parallel.ForEachAsync(myList, new ParallelOptions { MaxDegreeOfParallelism = 10 }, async (item, token) =>
{
await CallApiAsync(item, token);
});foreachawaitTask.WhenAllParallel.ForEachAsyncParallel.ForEachasync voidlist.ForEach(async item => await ...)async void