Noamwa值类型和引用类型的区分，很多程序员从第一门语言就开始背"值类型在栈上，引用类型在堆上"这句话。但说句实在话，这句话在面试里能帮你过关，到了线上环境却几乎不能帮你解决任何问题。真正让人半夜爬起来改代码的，往往是赋值时"值复制了但对象还共享着"、传参时"函数里的改动悄悄流到了函数外面"、并发时"一个线程改了数据别的线程全乱了"这一类的实际影响。这篇文章不想再给你画一张内存示意图让你背，而是从我真实踩过的坑出发，把值类型与引用类型在性能、并发、API设计、数据流控这几个方向上的实际影响讲透，顺便纠正一下"栈和堆"这个过于简化的印象。
1. 一个让我半夜起来改代码的Bug：值类型和引用类型的"身份"差异
1.1 现象：改了A，B和C全都跟着变了
事情发生在一个内部工单系统里，我负责重构一个"标签配置"模块。需求很简单：管理员可以给工单设置标签组，每个标签组里有多个标签；前端编辑标签组时，支持"复制一份配置作为草稿，改完再发布"。听起来完全没难度，结果联调的时候发现：你在草稿里改了标签名，点保存发现线上配置也跟着变了。
当时的代码逻辑大致是这个样子（用TypeScript描述）：
typescript复制const tagGroup = await loadTagGroup(3);
const draft = tagGroup; // 想复制一份当草稿
draft.tags.push({ id: 99, name: "紧急" });
await saveTagGroup(tagGroup); // 只是想把草稿保存一下？
第一次看到这个现象，我整个人是懵的。我明明创建了一个draft，往draft里加了标签，为什么原对象tagGroup也变了？更诡异的是，接口返回的tagGroup是全新的对象，我甚至没有执行保存草稿的接口，线上配置就被污染了。当时的第一反应是后端有缓存、Redis没失效、或者同事代码里有鬼，压根没想到是前端这段赋值代码的问题。
1.2 排查过程：从业务逻辑一路怀疑到内存模型
排查从最外层开始。先看接口调用记录，确认刷新页面后确实发了一个"保存标签组"的请求；再看后端日志，发现保存的标签组里已经包含了{ id: 99 }这条新标签；最后在代码里逐行打断点，断点停在draft.tags.push(...)时，右侧变量面板里tagGroup.tags和draft.tags高亮的是同一个内存地址。
到这里我才意识到，问题压根不在后端，而是const draft = tagGroup这行代码。在TypeScript/JavaScript里，对象类型走的是引用语义：draft和tagGroup这两个变量名指向的是唯一一个对象。你以为自己在"复制"，其实只是在给同一个对象贴了第二张标签，任何一边修改，另一边马上可见。
1.3 根因："复制"和"共享"的本质区别
这个Bug的本质，是值语义和引用语义的差异没在脑子里形成条件反射。值类型（如number、string、boolean、结构体）在赋值时默认执行值复制，两个变量从此各自独立，怎么改都互不影响；引用类型（对象、数组、类实例）在赋值时复制的是引用/指针，两个变量名指向同一个堆里的对象，任何一方修改，另一方都会感知。
你得记住一个转换：值类型赋予的是"一份数据"，引用类型赋予的是"一个身份"。当你把一个对象赋值给另一个变量时，你做的事不是复印了一份文件，而是递了一张写着同一个保险柜地址的钥匙卡。很多人以为这是"栈和堆"的位置问题，其实核心是共享还是复制这个语义问题。内存位置只是这个语义在特定运行时下的一种体现，这一点放到后面细说。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 先明确基本盘：值类型和引用类型的本质差异
2.1 内存位置只是结果，不是原因
教科书通常会画一张图：栈帧里放着基本类型，堆里放着对象。图示很直观，但它带来的副作用是把"栈/堆"当成了原因，让人觉得"只要拿栈和堆就能判断值类型还是引用类型"。真实情况要复杂得多，引用类型对象本身在堆里，但如果方法内新建的对象没有逃逸出方法作用域，JIT可能直接在栈上分配它；值类型的字段如果被一个引用类型持有，它也会跟着被搬进堆里；还有装箱场景：把一个int赋值给object，这个int会被包装成堆上的对象——栈