.NET Framework 与 .NET Core 在 Task 调度、线程池、AsyncLocal 和并行计算等方面存在关键差异：前者依赖 SynchronizationContext 易致死锁，后者默认无上下文、自适应线程池、AsyncLocal 始终有效、PLINQ 并行度更高。
Task 默认调度器不同导致 await 行为差异
.NET Framework 的 Task 默认使用 WindowsFormsSynchronizationContext（WinForms）或 AspNetSynchronizationContext（ASP.NET Web Forms / MVC），await 后会自动回到原始上下文线程；.NET Core 完全移除了这些上下文，await 默认继续在线程池线程执行，不保证返回原上下文。
- ASP.NET Core 中
ConfigureAwait(false)已无实际意义——因为本来就没有SynchronizationContext - .NET Framework 下 WPF/WinForms 项目若未显式调用
ConfigureAwait(false)，UI 线程 await 后续代码可能被阻塞，引发死锁（尤其在同步等待Task.Result时） - ASP.NET Framework（非 Core）中，同步阻塞异步调用（如
task.Wait()）极易触发请求上下文死锁，而 ASP.NET Core 不会
ThreadPool 默认配置与可伸缩性表现不同
.NET Core 从 2.1 起采用自适应线程池（ThreadPool.UnmanagedThreadPool 启用优化），初始最小线程数默认为 1（ThreadPool.SetMinThreads 不再影响底层行为）；.NET Framework 的线程池依赖固定启发式算法，最小线程数默认为逻辑处理器数，且长期存在“饥饿”问题——高并发短任务下线程增长滞后，导致延迟突增。
- .NET Core 中
ThreadPool.GetMinThreads返回值可能与实际调度不符，不应依赖它做容量预估 - .NET Framework 下手动调用
ThreadPool.SetMinThreads(100, 100)是常见调优手段；.NET Core 中该调用仅影响托管线程池的“软限制”，底层 unmanaged pool 仍自主伸缩 - 在突发 I/O 密集型负载（如大量
HttpClient请求）下，.NET Core 线程池响应更快，排队时间更短
AsyncLocal 跨 await 的数据传递行为一致但需注意作用域泄漏
两者都通过 ExecutionContext 流传 AsyncLocal<t></t> 值，语义一致。但 .NET Framework 在某些旧版 IIS 集成模式（如 Classic Mode）中，ExecutionContext 可能意外截断；.NET Core 则始终保证完整传播。
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- 在中间件或过滤器中设置
AsyncLocal<string> _traceId = new()</string>，后续所有await调用都能读取，无需额外捕获 - 务必避免将
AsyncLocal<t></t>实例存储到静态字段并跨请求复用——值会在请求间“残留”，造成数据污染 - .NET Framework 下若禁用
executionContext（配置<legacycorruptedstateexceptionspolicy enabled="true"></legacycorruptedstateexceptionspolicy>），AsyncLocal会失效；.NET Core 不支持该配置，始终启用
并行集合与 PLINQ 的线程安全模型没有本质变化，但默认并发度策略更激进
ConcurrentDictionary<tkey tvalue></tkey>、ConcurrentQueue<t></t> 等类型 API 完全兼容，行为一致。区别在于 PLINQ（AsParallel()）默认最大并行度：.NET Framework 使用 Environment.ProcessorCount，而 .NET Core 2.0+ 默认设为 ProcessorCount * 2（I/O 或混合负载更友好）。
- PLINQ 查询中若含非线程安全操作（如写入普通
List<t></t>），无论哪个平台都会出错——不能依赖“默认更安全” - 在 CPU 密集型场景下，.NET Core 的更高默认并行度可能导致上下文切换开销上升，此时应显式调用
WithDegreeOfParallelism(4) -
Parallel.ForEach的MaxDegreeOfParallelism行为一致，但 .NET Core 对ParallelOptions.TaskScheduler的自定义调度器支持更稳定
var options = new ParallelOptions
{
MaxDegreeOfParallelism = 4,
TaskScheduler = new ConcurrentExclusiveSchedulerPair().ExclusiveScheduler
};
Parallel.ForEach(items, options, item => { /* ... */ });.NET Core 的并发模型更贴近现代硬件与云环境，但这也意味着：你不能再靠“碰巧没出问题”的旧习惯（比如在 ASP.NET Framework 里同步阻塞异步方法）蒙混过关——错误会立刻暴露，而不是等压测时才崩。
