automapper 不自动猜映射，需显式配置 createmap 和 formember；属性名不一致（如 createddate→createdat）必须手动指定，否则为空；嵌套映射需显式展开或单独配 createmap；assertconfigurationisvalid() 是上线前必调的验证项。
AutoMapper 对属性名不一致的映射不是“自动猜”，而是靠显式规则驱动；没配 CreateMap 或漏写 ForMember，就根本不会映射——哪怕只差一个大小写或下划线。
字段名完全不同时必须用 ForMember + MapFrom
默认只匹配大小写不敏感的同名属性。比如源类有 CreatedDate，DTO 里叫 CreatedAt，不声明就为空。别指望 AutoMapper 自己“脑补”关系。
-
ForMember的 lambda 表达式里，src必须能安全访问路径：用src.User?.Id比src.User.Id更稳，避免NullReferenceException - 别在
MapFrom里调用服务或 DB 查询（如src => _repo.GetUserById(src.UserId)），这会让一次Map()变成 N+1 查询 - 字符串拼接、日期计算等纯内存操作可以放进去，但高频列表映射时，优先考虑
NullSubstitute而非?? "N/A"，后者绕过表达式树编译，GC 压力明显上升
嵌套属性扁平化映射要关掉自动推导或显式配置
源对象是 User.Address.Street，目标 DTO 是 Street 或 AddressStreet，AutoMapper 默认会尝试扁平化，但行为不可控——尤其当多个嵌套层级出现同名字段（如 User.BillingAddress.City 和 User.ShippingAddress.City）时，容易映射错。
- 禁用全局扁平化：
cfg.CreateMap<user userdto>().ForAllMembers(opt => opt.Condition((src, dest, srcMember, destMember) => srcMember != null));</user>不推荐，太粗暴 - 更稳妥的是显式展开：
.ForMember(dest => dest.Street, opt => opt.MapFrom(src => src.Address.Street)) - 如果嵌套类型本身也需要映射（如
Address→AddressDto），必须单独配CreateMap<address addressdto>()</address>，否则ProjectTo<userdto>()</userdto>会失败
AssertConfigurationIsValid() 不是可选项，是上线前必跑的检查项
没调这个方法，你永远不知道哪些映射规则其实根本没生效。常见静默失败场景：属性名拼错、泛型参数顺序颠倒、Profile 构造函数外写了 CreateMap（AutoMapper 直接忽略）。
- 在
Program.cs配置完AddAutoMapper后，加一行：mapper.ConfigurationProvider.AssertConfigurationIsValid(); - 它会在启动时报出具体哪对类型没配、哪个属性没映射、哪个
MapFrom表达式编译失败 - CI 流程里建议作为构建检查项，避免带残缺映射的代码进测试环境
最常被跳过的其实是 Profile 类的构造函数约束：所有 CreateMap 必须写在里面，且不能有异步逻辑、不能依赖注入服务实例——因为 Profile 实例化发生在 DI 容器构建前。这点一旦踩坑，错误信息往往指向“配置不可变”，而不是“你把 CreateMap 写错地方了”。
