AutoMapper 配置是否线程安全？
是的，
MapperConfiguration实例本身是线程安全的，且设计为**全局单例复用**。一旦构建完成，它可被任意数量的线程并发调用
CreateMapper()或直接通过
IMapper实例映射——但关键点在于：你不能在运行时动态修改配置（比如调用
AddProfile或
CreateMap），否则会触发内部锁并引发
InvalidOperationException：“The configuration is locked and cannot be modified.”
常见错误现象：
在 Web API 的每个请求中 new 一个MapperConfiguration→ CPU 和内存暴涨，GC 压力大 把
MapperConfiguration放进 DI 容器但注册为
Scoped或
Transient→ 配置重复初始化，失去缓存优势
正确做法：
在Program.cs或
Startup.ConfigureServices中一次性构建
MapperConfiguration注册为
Singleton，并用它创建
IMapper（也注册为
Singleton）
IMapper 实例是否可被多线程共享？
可以，
IMapper是线程安全的，内部不保存请求上下文或可变状态。它的核心方法如
Map<t>()</t>、
ProjectTo<t>()</t>都是无状态的纯函数式调用。
但要注意两个隐含陷阱：
如果你在自定义ValueResolver、
IMemberValueResolver或
ITypeConverter中用了静态变量或共享集合（比如缓存字典未加锁），就会引入线程竞争
Map(source, destination)这种就地更新操作，若
destination是跨线程复用的对象，需确保该对象自身线程安全（AutoMapper 不负责保护你的目标实例）
性能影响：
每次Map()调用都会查表定位映射计划，这个查找是 O(1) 的哈希查找，开销极小 真正耗时的是首次类型映射时的表达式树编译（发生在第一次调用时），后续全部走已编译委托
高并发下 AutoMapper 的实际瓶颈在哪？
不是 AutoMapper 本身，而是你没关掉的调试行为和低效配置模式。
典型问题：
Validate()在生产环境仍被调用 → 每次映射前反射扫描所有属性，CPU 直接翻倍 大量使用
ForMember(...).Ignore()+ 手动赋值逻辑 → 阻止了 AutoMapper 的表达式树优化路径 用
ConvertUsing<customconverter>()</customconverter>但
CustomConverter内部做了同步 IO（如查数据库）→ 线程池饥饿
实操建议：
生产环境务必关闭验证：var config = new MapperConfiguration(cfg =>
{
cfg.AddProfile<MyProfile>();
// 不要写 cfg.Validate();
});
避免在 ForMember中调用复杂方法；改用
ConvertUsing并确保转换器无副作用、无阻塞 对高频映射类型（如 DTO ↔ Entity），用
ProjectTo<t>()</t>替代
Map<t>()</t>，让 EF Core 直接生成 SQL 投影，绕过内存映射
为什么有时候高并发下出现 MappingException 或空引用？
绝大多数不是线程安全问题，而是配置漏写或类型不匹配在并发压力下暴露得更早。
例如：
忘记为某个子类型配置CreateMap<a b>()</a>，在低并发时可能靠默认映射“碰巧”跑通，高并发时因执行路径不同触发校验失败 源对象字段是
Nullable<int></int>，目标是
int，又没配
NullSubstitute→ 多线程同时遇到 null 值时批量抛出异常 Profile 中用了
IncludeBase<basesrc basedst>()</basesrc>，但基类映射未定义 → 首次并发调用时多个线程同时尝试初始化，可能触发竞态（虽罕见，但 .NET 6+ 已修复）
最容易被忽略的一点：AutoMapper 不处理循环引用的自动检测（除非显式启用
MaxDepth）。高并发下，如果对象图存在隐式循环（如 A→B→A），不同线程可能在不同深度触发栈溢出或空引用，表现不稳定。
