在 Excel 里录入备注时，很多用户的肌肉记忆是：输入第一行文字，按 Alt+Enter 换到第二行，继续输入，回车确认。这个习惯被原样带到了基于 SpreadJS 的 Web 表格应用里——换行符确实写进了单元格。但屏幕上出现的却是一行挤在小格子里的长文本：换行符没有生效，行高也没有变化，用户只能再手动设置一次"自动换行"，再手动拖一下行高。

为什么这个细节重要

问题出在数据与显示的错位上。Alt+Enter 写入的只是一个 \n 字符，值本身已经完整保存；但单元格默认不开启 wordWrap，行高也是固定值，于是"数据是对的、显示是错的"。用户看到的不是自己刚输入的两行内容，而是一条被截断的单行文本。

受影响的不只是录入者本人。备注、地址、审批意见这类多行字段往往还要流转给别人看，显示不全意味着信息在第一个环节就丢了。产品经理会把它当成"表格不好用"的反馈提出来，而开发者面对的是一个很小的缺口：只差两步收尾动作。

SpreadJS 的实现思路

SpreadJS 作为 JavaScript 电子表格控件，提供了事件层面的挂点。监听 GC.Spread.Sheets.Events.ValueChanged，在值提交进单元格的那一刻检查新值里有没有换行符；有，就把该单元格的 wordWrap 打开，再调用 autoFitRow 让这一行的行高适配内容：

const spread = new GC.Spread.Sheets.Workbook(document.getElementById("ss"));
​
spread.bind(GC.Spread.Sheets.Events.ValueChanged, function (sender, args) {
    let str = args.newValue;
    if (str.indexOf("\n") >= 0) {
        args.sheet.getCell(args.row, args.col).wordWrap(true);
        args.sheet.autoFitRow(args.row);
    }
});

这段逻辑只有几个关键点。ValueChanged 绑定在工作簿上，编辑结束、值真正写入时触发，回调里的 args.newValue 就是刚提交的内容，用 indexOf("\n") >= 0 判断是否包含换行符即可。命中之后先对 args.sheet.getCell(args.row, args.col) 调用 wordWrap(true)——这是单元格级样式，只影响当前格，不会波及整表。最后 autoFitRow(args.row) 按内容重算行高，两行文字就能完整露出来了。

顺序也有讲究：先开换行再算行高，autoFitRow 才会按"多行"来计算；反过来做，行高会按单行文本得出，结果仍然不对。

可以扩展到哪些场景

• 财务与业务系统备注栏：摘要、说明、驳回意见等字段允许换行，录入即排版。
• 客户主数据维护：地址、联系人备注常含多段文字，避免客服反复手工调整格式。
• 审批流表单：处理意见多行展示，后续查看人不需要点开单元格才能读完。
• 数据导入后的补录界面：粘贴或补录长文本时自动整理显示，减少人工清洗。

给开发者的关键词

GC.Spread.Sheets.Events.ValueChanged、getCell(row, col).wordWrap(true)、Worksheet.autoFitRow(row)、换行符 \n、Alt+Enter、JavaScript 电子表格控件、Workbook / Worksheet 事件绑定。

小结

Excel 用户对 Alt+Enter 的期待是"输入即分行"，Web 表格只要补上检测换行符、开启 wordWrap、自适应行高这三步，就能把这份习惯完整接住。几行事件代码换来的是录入端少一次手工调整、阅读端少一次信息截断，这类细节正是 Web 表格贴近真实工作习惯的地方。

一个诚实的边界：这套做法只在"输入含换行符"时触发，如果用户事后删掉了换行符，已开启的 wordWrap 会保留，需要的话可以在同一事件里反向处理。