一个几乎每个 Unity 项目都在犯的错
先做个小测试。打开你的 Unity 项目，随便点开一个模型（fbx），看看它的导入设置里，那个Read/Write Enabled是勾着的还是没勾。
如果你从来没注意过这个选项，那大概率——你项目里一批模型正在白白吃掉双倍的内存，而你毫不知情。
这个设置极其隐蔽。它不报错、不警告，游戏跑起来一切正常，你甚至永远不会"发现"它有问题。它只是安安静静地，让你的每个网格在内存里存了两份，然后在某天你排查内存占用时，让你百思不得其解：“我模型不多啊，内存怎么这么高？”
这篇文章就来把这个坑讲透。而讲透它的过程，会顺带纠正一个几乎人人都有的直觉误解——“模型都显示出来了，那数据肯定得留着读吧？”这个听起来天经地义的想法，恰恰是错的。
先说结论：它到底在干什么
Read/Write Enabled 开启后，会让网格数据在内存里额外保留一份 CPU 可读写的副本。也就是说，同一个网格的数据存了两份，内存直接翻倍。
Read/Write 关闭： 网格数据 → 上传到 GPU 显存后，CPU 内存里那份就释放掉 → 最终只留一份 → 省内存 Read/Write 开启： 网格数据 → 上传到 GPU 显存后，CPU 内存里那份【硬留着】 → GPU 一份 + CPU 一份 → 内存翻倍！看到这你可能立刻会有那个经典的疑问：
“等一下。模型要显示在屏幕上，那肯定得有人去读它的顶点数据才能画出来啊。既然要读，那份数据不就必须留着吗？关掉它，模型还怎么显示？”
这个疑问非常好，因为它精准地命中了整个问题的核心误解。要解开它，我们得先搞清楚一件事：网格数据到底有几个"读者"。
关键：网格数据有两拨完全不同的读者
一个模型的网格数据（顶点坐标、三角面等），理论上会被两拨完全不同的角色读取。搞混这两拨人，就是所有困惑的根源。
网格数据，谁会来读它？ 读者一：GPU（显卡） 目的：把模型画到屏幕上（渲染） → 这是【显示】必须的 读者二：CPU（你的 C# 代码） 目的：在代码里读取或修改顶点数据 → 这是【只有特殊需求】才用到的现在回到你的疑问。你说"显示要读数据"——没错，但读数据的是"读者一 GPU"，不是"读者二 CPU"。
而Read/Write Enabled 管的，是"读者二 CPU"能不能读。它跟显示（读者一 GPU 的工作）没有任何关系。
这就是那层窗户纸：你把两个读者当成了一个人。你以为"显示 = 要读 = CPU 读 = 需要 Read/Write"，但实际上显示是 GPU 的活，走的是完全独立的另一条路。
显示模型时，CPU 其实早就"撒手"了
我们把模型加载并显示的完整流程走一遍，你就明白 CPU 是怎么全程置身事外的：
① 模型加载 → 网格数据先进内存（CPU 这边） │ ② 上传给 GPU → 数据被送进显存（GPU 那边） │ ③ 之后每一帧的显示 → GPU 从【自己的显存】里读数据来画 │ ④ 此时 CPU 内存里那份原始数据呢？ → 对于显示来说，已经完全用不到了！ → Read/Write 关着的话，系统就把它释放掉，省下这份内存盯住第 ③④ 步。一旦数据上传到 GPU 显存，之后每一帧画模型，都是GPU 从它自己的显存里读——GPU 手里有自己的一份，根本不需要回头找 CPU 那份。
所以 CPU 内存里最初那份数据，在"上传给 GPU"之后，对显示而言就功成身退、再无价值了。既然没用了，Read/Write 关着的话系统就顺手把它释放，内存就省下来了。
Read/Write 关：数据上传 GPU 后 → CPU 那份释放 → 只剩显存一份 → 显示照常！ Read/Write 开：数据上传 GPU 后 → CPU 那份硬留 → 显存+内存两份 → 白白翻倍！所以"关掉它模型就显示不出来"这个担心，是完全多余的。显示靠的是 GPU 显存里那份，CPU 那份留不留，跟显示一点关系都没有。关掉它，模型该怎么显示还怎么显示，你在游戏里看不出任何区别，只是内存少占了一半网格数据而已。
用一个类比彻底说透
如果还有点绕，来个类比。把网格数据想象成一份施工图纸：
上传给 GPU = 把图纸交给施工队（GPU），他们照着盖楼（显示） 施工队自己会复印一份带在工地上 Read/Write 关 = 图纸交出去后，你手里那份原件就不留了 → 楼照样盖（显示照常），你桌上少堆一份纸（省内存） Read/Write 开 = 图纸交出去后，你手里【也硬留一份原件】 → 目的是你自己随时想改图、想查图（代码读写） → 但如果你根本不打算改，留着就是白占桌面你的疑问，相当于问：“楼都盖起来了，那我手里肯定得留着图纸吧？”
不需要啊。楼是施工队照着他们那份复印件盖的，跟你手里留不留原件毫无关系。你手里那份，只在"你自己还想改图"时才有意义。
那这份 CPU 副本，到底给谁用？
既然显示不需要它，那开着 Read/Write、留着这份 CPU 数据，是给谁用的？
给你的 C# 代码用的。而且是相当特殊的需求——只有当你想在运行时用代码直接读取或修改网格本身时，CPU 手里才需要留着这份可读写的数据：
真正需要开 Read/Write 的场景（都比较特殊）： → 运行时用代码读取顶点坐标做计算 （比如：想精确知道网格上某个点在哪） → 运行时用代码修改网格形状 （比如：程序化捏脸、地形实时变形、把网格切开） → 某些需要 CPU 侧访问网格的特殊功能 （比如：运行时重新烘焙碰撞网格、某些网格合并操作）它们的共同点是：你要在代码里"碰"这个网格的数据。而"碰"这个动作是 CPU 干的，所以 CPU 手里必须留一份可读写的数据——这才是 Read/Write 开着的唯一意义。
现在你回头想想：你项目里绝大多数模型——石头、房子、桌子、角色、道具、树、宝箱——你会在运行时用代码去读它们的顶点、改它们的形状吗？
不会。它们导入进来就那样摆着、动着、显示着，你的代码从来不去触碰它们的网格数据。
对这些模型（也就是绝大多数模型），那份 CPU 副本就是纯粹白留的——没有任何代码读它，它就在那儿干占内存。这就是它"隐蔽又常见"的原因：默默留着一份谁都不用的数据，而你浑然不觉。
顺手解决一个连带的困惑：物体移动算不算"读写"？
讲到这，很多人会冒出第二个疑问：
“我的模型在游戏里到处跑、会旋转、会缩放，这难道不算在’修改’它、不需要 Read/Write 吗？”
不算。这又是一个容易混的点，一并说清：
物体移动、旋转、缩放： → 改的是这个物体的【位置 / 朝向 / 大小】（Transform） → 网格数据本身（顶点的相对位置）一个字节都没变 → 不需要 Read/Write Read/Write 管的是： → 改【网格数据本身】（把顶点从这挪到那，让模型变形） → 这才需要 Read/Write打个比方：一辆车开来开去（移动），车的形状没变；而 Read/Write 管的是"把车顶敲扁"（改形状本身）。前者是绝大多数物体的日常，不需要 Read/Write；后者才是特殊需求。
实践建议：怎么处理它
道理讲透了，落到操作上：
① 默认就该是关的，绝大多数模型都不用开。
你的判断标准只有一句话：“我会在运行时用代码去读取或改变这个网格本身吗？”答案是"不会"（对绝大多数模型都是）→ 保持关闭，白省一半网格内存。
② 它在模型导入设置里，随时可改，很安全。
这个设置不改动源文件，勾错了随时能改回来。放心地关，去游戏里看一眼，你会发现显示毫无变化。
③ 用自动化守住底线，别靠人工逐个检查。
项目大了，靠人一个个点开检查不现实。用AssetPostprocessor在导入时按规则自动处理，比如"某目录下的静态道具，一律关掉 Read/Write"：
publicclassMeshImportRule:AssetPostprocessor{voidOnPreprocessModel(){ModelImporterimporter=(ModelImporter)assetImporter;// 默认一律关闭 Read/Write，需要的模型再单独例外处理importer.isReadable=false;}}让机器帮你守住这条底线，比指望每个人都记得靠谱得多。
总结
回到开头那个勾选框。现在你应该彻底看清它了：
你的直觉：显示模型肯定要读数据，所以得开 Read/Write？ 真相： ① 显示模型的"读"，是 GPU 从显存读，不是 CPU 读 ② Read/Write 管的是"CPU 能不能读"，跟显示无关 ③ 数据上传 GPU 后，显示就不再需要 CPU 那份了 ④ 所以关掉它，显示完全正常，只是省了 CPU 那份内存 ⑤ 只有当你要用【代码】读写网格本身时，才真需要开 ⑥ 绝大多数模型你根本不会用代码碰它 → 该关这个坑之所以隐蔽，根源在于我们太容易把"显示需要数据"直觉地等同于"CPU 得留着数据"，却忽略了显示其实是 GPU 的活，用的是 GPU 自己那份。
而更深一层，它其实是一个通用原则的缩影：别为你用不到的能力买单。Read/Write 提供的是"用代码读写网格"这个能力——你用不到它，就没有任何理由为它付出双倍内存的代价。
Unity 里这样的"能力开关"还有不少（比如模型上用不到的骨骼、顶点色、多余的 UV 通道，同理都在为用不到的能力占着内存）。当你养成一个习惯——看到任何一个开关，先问"它到底在为谁服务？我用得到吗？"——你就不会再被这些设置的表象绕进去，也不会再在某天对着莫名其妙的内存占用抓耳挠腮了。
去检查一下你项目里那些模型的 Read/Write 吧。可能有一批双份内存，正等着你一键省下来。
