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