手动投影是构造匿名类型的最直接方式，本质是编译器生成的只读类，不可提前声明或跨方法传递；标准写法为 new { obj.Name, obj.Age }，字段名可显式命名，适用于LINQ投影等场景。
用 new { } 手动投影是最直接、最可控的方式
匿名类型本质是编译器生成的只读类，不能提前声明、不能跨方法传递，所以“把已有对象转成匿名类型”其实是个伪命题——你真正需要的是“用原对象的字段构造一个新匿名对象”。new { obj.name, obj.age } 这种写法就是标准解法。
常见错误是试图用反射或序列化“自动转换”，结果要么丢失类型信息，要么性能差，还容易在 LINQ to Entities 场景下报 NotSupportedException。
- 只取需要的字段，避免带入敏感属性（如
PasswordHash） - 字段名会自动推导，但可显式命名：
new { FullName = obj.FirstName + " " + obj.LastName, obj.Id } - 匿名类型在方法返回时会丢失类型信息，别用作 public 方法返回值
用 JsonSerializer.Deserialize<object> 做运行时形状抹平要小心
如果目标是“丢掉原始类型，只留数据结构”，比如为 API 响应做轻量裁剪，JSON 序列化+反序列化是一种绕行方案。但它不是类型转换，而是先序列化再解析成 JsonElement 或 Dictionary<string, JsonElement>。
问题在于：原始对象里的 DateTime、decimal、null 会被 JSON 规则重解释；循环引用直接抛 JsonException；且无法保留字段顺序或自定义命名策略。
- 适合一次性、非关键路径的数据清洗，比如日志打点前的脱敏
- 用
JsonSerializerOptions.PropertyNamingPolicy = JsonNamingPolicy.CamelCase可统一命名风格 - 别对高频调用逻辑用它，序列化开销远高于手动 new
LINQ 查询中 Select 是最自然的匿名类型生成场景
当你从 IQueryable<User> 或 IEnumerable<Order> 中提取子集时，Select(x => new { x.Id, x.Status }) 不仅语义清晰，还能被 EF Core 翻译成 SQL 的 SELECT id, status，避免加载整行数据。
容易踩的坑是混用内存集合和数据库查询：若 Select 前已调用 ToList()，后续 new { } 就在内存执行，失去数据库端投影优化。
- EF Core 6+ 支持嵌套匿名类型（如
new { User = new { x.Name }, x.OrderCount }），但深度别超 3 层 - 字段名必须是合法标识符，
new { x.CreatedAt.Date }会报错，得写成Date = x.CreatedAt.Date - 匿名类型字段不能为
null（除非是可空类型），new { x.Manager?.Name }需补默认值或判空
别用 ExpandoObject 冒充匿名类型
ExpandoObject 是动态类型，支持运行时增删属性，但和匿名类型完全不兼容：不能用 var x = new ExpandoObject(); x.Name = "a"; 后再当匿名类型用，编译器不认识它的结构，LINQ 里也会崩。
它适合插件系统、配置解析等需高度动态的场景，但如果你只是想“换个形状传数据”，它只会增加类型不确定性、调试难度和 GC 压力。
-
ExpandoObject转Dictionary<string, object>是安全的，但反过来不保序 - 用它接收 JSON 时，数值默认是
long或double，没有int/decimal区分 - 和匿名类型一样，它不能作为接口参数或泛型约束使用
匿名类型的核心限制在于“编译期封闭”——你永远没法在另一个方法里写出匹配它的 var 参数。所以真正难的不是怎么造出来，而是想清楚：这个形状到底要在哪一层存在、谁来消费、是否需要序列化或跨线程传递。这些决策比语法本身影响更大。
