数据核对岗的同学大概都经历过这样的时刻：在 Web 表格里框选一大块区域，按下 Ctrl+C，页面突然不动了——表格不刷新，按钮点不了，浏览器标签页上转着圈。等它恢复要几秒钟，甚至弹出"页面无响应"。用户的第一反应是系统崩了，第二反应是换个更"快"的工具。复制是表格里最没有存在感的操作，正因为太日常，一旦出问题，信任流失得很快。

为什么这个细节重要

前端复制大区域慢，有客观原因。浏览器环境下，把成千上万个单元格序列化进剪贴板、再维持内部状态，都是主线程上的同步工作；单元格若带公式、样式或条件格式，计算量还会放大。SpreadJS 作为在浏览器里跑的 JavaScript 电子表格控件，处理上万格的复制时同样可能让页面明显停顿。

问题在于这种停顿发生在"无声处"：界面冻结前没有任何预警，用户不知道是卡了还是死了，只能反复按键、重复点击，甚至强刷页面丢掉未保存的内容。与其事后优化到极限，不如换一种产品化思路——在执行前先估算工作量，超过安全阈值就明确告知并拦下。宁可让用户分两次复制，也不让他面对无响应。

SpreadJS 的实现思路

SpreadJS 的交互动作建立在命令（Command）体系之上，Ctrl+C 触发的是 GC.Spread.Sheets.Commands.copy 命令。命令对象带有 execute 方法，且公开可替换：先保存原函数，再赋一个新函数过去，就能在原逻辑前后插入自己的检查。新函数里通过 context.getSheetFromName(options.sheetName) 拿到目标工作表，用 getSelections() 遍历选区；注意整列选择时 Range 的 row 为 -1，行数应取 sheet.getRowCount()，整行同理取 getColumnCount()。累加各选区的行列乘积，就得到本次复制的单元格总数。

let oldExecute = GC.Spread.Sheets.Commands.copy.execute;
GC.Spread.Sheets.Commands.copy.execute = function (context, options) {
    let sheet = context.getSheetFromName(options.sheetName);
    let count = 0;
    for (let range of sheet.getSelections()) {
        let rowCount = range.row === -1 ? sheet.getRowCount() : range.rowCount;
        let colCount = range.col === -1 ? sheet.getColumnCount() : range.colCount;
        count += rowCount * colCount;
    }
    if (count > 100) {
        alert("复制失败，单元格数量过多");
        throw new Error("Copy too many cells maybe very slow.");
    }
    return oldExecute(context, options);  // 未超限则走原生复制
};

超限时先提示再抛错，错误中断了命令流程，原生复制不会执行，页面保持响应；正常范围则原样调用 oldExecute，行为与默认一致。阈值 100 只是演示用的保守值，实际可按用户机器水平调大，或把 alert 换成 toast、引导分批复制。同样的包装也适用于 Commands.cut 和 Commands.paste。

可以扩展到哪些场景

• 财务月结底稿：金额表动辄数千行，限制单次复制规模，避免月末卡顿。
• 客服工单台：坐席频繁小段复制，拦截超大选区，保证高峰时段可用。
• 生产排程表：计划员习惯整列整表搬数据，前置提示比卡死后重试省时间。
• 数据脱敏场景：在包装函数里检查选中区域是否含敏感字段，超范围即拒绝。
• 自动化脚本防护：防止宏或插件误触发全表复制，拖垮演示环境。

一点诚实的边界：这是"预防"而非"加速"，超限操作被挡在门外，并没有变快。若业务必须支持大规模复制，还应结合 suspendPaint/resumePaint 减少重绘，或评估 TableSheet 这类大数据方案。

小结

复制卡死的根因是"开销与预期错位"：用户以为复制很轻，系统却背着一整个选区的成本。给 copy 命令加一道闸门，把可能的冻结变成一句明确提示，体验就从"碰运气"回到"可控"。这类改造不动组件内核，却最能体现表格系统的成熟度。