"制作副本"（整个文件）与"复制到"（单个标签页）之间的这一差异，是财务团队模型模板损坏最常见的根源。
复制后哪些内容保留，哪些丢失
| 复制方式 | 命名范围 | 引用命名范围的公式 | 使用命名范围的数据验证 |
|---|---|---|---|
| 文件 > 制作副本（整个电子表格） | 随之复制 | 完整保留 | 完整保留 |
| 标签页 > 复制到 > 新建电子表格 | 不会复制 | 改写为 A1 表示法 | 丢失来源 |
| 标签页 > 复制到 > 现有电子表格 | 不会复制 | 改写为 A1 表示法 | 丢失来源 |
Google Sheets 文档明确说明："命名范围的作用域是电子表格，而非单个工作表。"这意味着，一旦你将某个标签页从文件中单独提取出来，它所引用的所有命名范围要么被改写，要么成为孤儿引用。
公式引用悄无声息地被转换。 如果命名范围指向的是被复制的同一工作表上的某个单元格，Sheets 会将其改写为 A1 表示法。=折现率 变成 =假设条件!$B$4。公式照常运行，但你失去了让公式"自我说明"的可读性层--审计模型的人看到的是原始地址，而非业务含义。
跨标签页的命名范围则会直接报错。 如果命名范围指向的工作表未被纳入本次复制，你将得到 #REF! 或 #NAME?。在一个包含 8 个标签页的模型中，WACC、税率、永续增长率、汇率等假设条件全部存放在一张中央"假设条件"表上，这会触发一连串的级联错误。
数据验证功能失效。 任何以命名范围为来源的下拉菜单都会失去来源。单元格保留上次输入的值，但新录入的内容不再经过验证。
Google Sheets 每个电子表格最多支持 1,000 个命名范围（参见 Sheets API v4 配额文档）。大多数 FP&A 模型使用的数量在 8 到 30 个之间--少到让人觉得手动重建似乎可行，多到一旦模板复制将其全部清除时真的令人头疼。
FP&A 团队实际遭遇的三类场景
季度董事会汇报材料模板。 你精心搭建了一套 Q4 汇报模板--营收 4200 万元、毛利率 38.5%、EBITDA 620 万元--并为 报告期、汇率、预算营收 设置了命名范围。你将利润表标签页复制到一个新的 Q1 文件中。公式被改写为硬编码地址，但由于 Q1 文件尚不存在"假设条件"标签页，大约一半的公式解析为 #REF!。你花了 45 分钟追溯那些你以为已经清晰标注过的引用。
逐主体并表模型。 你的单主体 LBO 模型共 8 个标签页。你通过"制作副本"将其克隆 4 份，构建 4 主体结构--没有问题，命名范围全部保留。随后你将主体一的"营收"标签页复制到主体三中，以统一口径。每一次跨文件的标签页移动，命名范围就断裂一次。
将标签页嵌入现有模型。 你在一个独立文件中搭建了完整的资金瀑布分析，现在需要将其并入银团融资的 DCF 分析包。你复制了该标签页。所有命名范围引用都改写为源文件的地址，而这些地址在目标文件中指向的是虚空。
三种保留命名范围的解决方案
方案一：使用显式标签页引用，提升可移植性
对于多个工作表都需要引用的假设条件，可以完全放弃命名范围，直接使用标签页引用：
// 跨"复制到"操作时容易断裂：
=NPV(WACC, '现金流'!C5:C14)
// 具备可移植性：
=NPV(假设条件!$B$4, '现金流'!C5:C14)
可读性稍差，但只要"假设条件"标签页随之迁移，任何复制操作都不会造成断裂。对于需要反复模板化和复制的模型--季度汇报包、客户模型、并表结构--这是维护成本更低的选择。
方案二：用 Apps Script 重建命名范围（一次性运行）
如果你的常规工作流中包含"复制到"操作，可以使用以下 Apps Script 在目标文件中一次性重建命名范围。将脚本粘贴到目标文件的"扩展程序 > Apps Script"中，根据你的模型更新 definitions 对象，然后运行一次即可。
// 在将工作表复制到新文件后运行一次。
// 根据硬编码的定义映射重建命名范围。
function rebuildNamedRanges() {
var ss = SpreadsheetApp.getActiveSpreadsheet();
// 映射：命名范围 -> 工作表名称!单元格
var definitions = {
'WACC': '假设条件!B4', // 9.2% 加权平均资本成本
'TerminalGrowthRate': '假设条件!B5', // 2.5% 永续增长率
'TaxRate': '假设条件!B6', // 27% 有效税率
'ReportingPeriod': '假设条件!B2', // "FY2026"
'FXRate_USD_CNY': '假设条件!B9' // 2026年6月汇率
};
var rebuilt = 0;
for (var name in definitions) {
var parts = definitions[name].split('!');
var sheet = ss.getSheetByName(parts[0]);
if (sheet) {
ss.setNamedRange(name, sheet.getRange(parts[1]));
rebuilt++;
}
}
Logger.log('已重建 ' + rebuilt + ' 个命名范围。');
}
运行耗时约 3 秒。建议将这段函数以注释形式保存在模板"假设条件"标签页中，方便后续接手模型的人随时找到并使用。
方案三：复制整个文件，再删除不需要的内容
如果你需要命名范围保持完整，请对整个电子表格使用"文件 > 制作副本"，然后删除不需要的工作表。操作上不够精细，但命名范围、数据验证和跨标签页引用都能完整保留。对于模型结构稳定、只需滚动更新报告期的季度模板，这个方法通常比逐标签页管理复制更为高效。
截至 2026 年 6 月，Google Sheets 原生界面尚不支持在"复制到"操作中同步迁移命名范围。这一局限已存在多年，当前 Sheets API v4 文档中也未见相关改进计划。
命名范围文档化建议
如果你构建的模型日后需要被复制--大多数 FP&A 模型都会如此--建议在文件中专门设立一个 命名范围 标签页。一张三列表格，记录 范围名称 → 工作表!单元格 → 说明，大约需要 20 分钟完成。
范围名称 | 单元格 | 说明
WACC | 假设条件!B4 | DCF 折现率所用加权平均资本成本
TerminalGrowthRate | 假设条件!B5 | 预测期后的永续增长率
TaxRate | 假设条件!B6 | 企业有效税率
FXRate_USD_CNY | 假设条件!B9 | 月末汇率，美元兑人民币
ReportingPeriod | 假设条件!B2 | 报表抬头所用财年标签
每当"复制到"清空你的命名范围，这张表就是你的重建指引。如果进一步将 Apps Script 中的 definitions 对象改为从该标签页动态读取，而非硬编码，你就拥有了一套能够自我修复的文档化模板。
像 =SUMIFS('损益表'!C:C,'损益表'!B:B,">="&假设条件!$B$3) 这样的跨标签页公式，即便没有命名范围也能正常运行--但业务意图已被埋藏在地址里。命名范围让模型审查更高效，而高效的模型审查意味着在交割前与银团方的来回沟通更少。
ModelMonkey 可以对复制后的模型进行审计，定位因命名范围断裂导致的 #NAME? 和 #REF! 错误，并根据你的"假设条件"标签页结构自动重建--比在模板复制出错后手动逐一追溯 40 个公式快得多。
查看 ModelMonkey 方案--同时支持 Google Sheets 和 Excel。
常见问题
Q：在 Google Sheets 中执行「复制到」操作后，命名范围为什么会消失？
A：因为命名范围的作用域是整个电子表格，而非单个工作表。当你将某个标签页复制到另一个文件时，命名范围本身留在源文件中，无法跟随单独的标签页迁移。目标文件中若不存在同名的命名范围，公式要么被自动改写为 A1 表示法，要么直接报 #NAME? 错误。
Q：「制作副本」与「复制到」在处理命名范围时有何不同？
A：「文件 > 制作副本」复制的是整个电子表格，命名范围会完整保留。「标签页 > 复制到」仅复制单个工作表，命名范围不会随之迁移。如果你的模型结构允许，优先使用「制作副本」再删除多余工作表，是保全命名范围最简单的方式。
Q：复制后公式仍然显示正确结果，是不是意味着命名范围没有问题？
A：不一定。如果命名范围原本指向的是同一张被复制的工作表，Sheets 会将其悄悄改写为等效的 A1 表示法（如 =WACC 变为 =假设条件!$B$4），公式结果不变，但可读性和可审计性已经丢失。只有当命名范围指向未被复制的工作表时，才会出现 #REF! 或 #NAME? 等明显报错。
Q：有没有办法在「复制到」后自动恢复命名范围？
A：Google Sheets 原生界面截至 2026 年 6 月尚不支持此功能。可行的替代方案是在目标文件中运行一段 Apps Script（见本文方案二），根据预先维护的定义映射表一次性重建所有命名范围，耗时约 3 秒。
Q：数据验证中使用的命名范围，「复制到」后还能正常工作吗？
A：不能。以命名范围为来源的下拉菜单会在复制后失去来源，单元格虽保留上次输入的值，但新录入的内容不再受验证规则约束。需要在目标文件中手动重新指定验证来源，或通过 Apps Script 批量修复。