应根据业务需求选择基本类型或引用类型：数据有独立业务含义且不可变时用基本类型；需共享状态和唯一标识时用引用类型；性能瓶颈真实存在时才优化；类型设计要考虑未来扩展性。
选基本类型还是引用类型，关键不在语法对错，而在业务是否需要“身份”、数据是否允许共享、性能有没有真实瓶颈。
看数据有没有独立业务含义
金额、年龄、开关状态这类概念天然独立、不可变、不依赖上下文，就该用基本类型。比如 decimal amount 表示订单金额，语义清晰、线程安全、不会空引用。若需扩展行为（如货币单位校验、四舍五入策略），可封装为不可变引用类型，如 Money 类——它不是为了“高级”，而是防止把 金额 当普通数字误加减或忽略精度。
看对象要不要被多个地方共同持有和修改
客户、订单、设备这些实体有唯一标识、生命周期、跨服务协作需求，必须用引用类型。比如 class Customer 在风控、积分、订单模块中被反复引用和更新，地址变了、等级升了，所有地方看到的都应是同一份状态。反过来说，如果只是临时算个“客户平均消费”，这个值本身没身份、不追踪变化，用 double 或只读结构体就够了，不必强建一个类。
看性能瓶颈是不是真存在
高频小数据（如每秒百万传感器读数）用 struct 可减少 GC 压力，但别盲目——结构体大小建议控制在 16 字节以内，且保持不可变；跨进程通信（如微服务间 JSON 传输）本质上传的是快照，此时用简单 class 做 DTO 更直观，值/引用语义反而次要；字符串虽是引用类型，但因不可变和 == 重载，日常就当业务字符串用，除非压测证明 ReadOnlySpan
看团队协作和未来能不能平滑演进
用 int orderId 看似省事，等哪天要支持 Snowflake 或 UUID 格式，所有接口、数据库字段、日志、测试用例全得动。换成 OrderId 类型，转换逻辑集中、校验内置、API 语义立刻清晰。方法参数也一样：写 void Process(OrderId id) 比 void Process(int id) 多不了几行代码，却让调用方无法传错类型，也方便日后加租户前缀、版本标识等扩展点。
