今天的企业表格，越来越少是孤立的。

销售报价要读取最新价格，库存计划要看实时库存，财务测算要取汇率，风控模型要调用评分服务，项目排期可能还要拿外部系统里的工时和状态。用户看到的是一张表，背后却连接着许多动态数据源。

这带来一个新问题：表格里的结果什么时候刷新？

如果每次打开页面都重新请求，可能慢，也可能打扰用户；如果完全不自动刷新，用户又担心数据已经过期。对很多业务系统来说，一个清晰的“刷新当前表格数据”入口，比看似聪明的自动刷新更让人安心。

公式不一定只做本地计算

传统电子表格给人的印象是：公式只在当前工作簿里计算。A 列加 B 列，汇总某个区域，按条件筛选结果。这些当然重要，但 Web 化以后，公式的边界正在变宽。

当表格嵌入业务系统后，公式可以成为连接外部数据和业务逻辑的表达方式。用户仍然用熟悉的单元格和公式理解结果，系统则在背后完成接口请求、异步计算或服务调用。

SpreadJS 支持自定义异步函数，这意味着公式不必只等待本地数据。它可以在计算过程中显示加载状态，并在异步任务完成后把结果返回到单元格中。对用户来说，表格仍然像表格；对系统来说，它已经能接入更复杂的数据来源。

这类能力非常适合实时价格、库存余量、外部指标、在线评分、远程计算等场景。

为什么需要“一键触发”

异步数据最难的不是取到结果，而是让用户理解结果是否最新。

如果每个单元格自己决定刷新，用户可能不知道哪些已经更新，哪些还在等待。若表格里有几十个异步公式，刷新过程更容易显得零散。业务人员打开报表时，往往只想做一件事：点击刷新，然后等待整张表进入最新状态。

SpreadJS 的公式引擎可以通过依赖关系触发重新计算。产品上可以把一组异步公式绑定到共同的刷新条件上，当这个条件变化时，相关单元格统一重新计算。这样就能形成一个清晰的操作模型：用户点击一次，工作表中依赖该条件的异步结果一起更新。

这比让用户逐个编辑单元格、逐个触发公式更自然，也更适合做成业务系统里的按钮、工具栏命令或定时刷新策略。

对产品体验意味着什么

一键刷新能给用户一个明确的心理预期。

在销售场景中，报价人员可以刷新最新价格和折扣规则；在库存场景中，计划人员可以刷新当前可用量；在财务场景中，分析人员可以刷新汇率、利率或外部指标；在运营场景中，团队可以刷新活动数据和渠道表现。

这些场景的共同点是：表格里有大量计算关系，但关键数据来自外部。用户既需要电子表格的灵活性，又需要业务系统的数据实时性。

SpreadJS 把这两者连接起来。异步函数让外部数据可以进入公式体系，重新计算机制让一批相关结果可以统一更新，加载状态则让用户知道系统正在处理，而不是页面卡住了。

这对产品经理尤其有价值。很多产品不是缺功能，而是缺一个用户能理解的操作闭环。刷新按钮、加载状态、结果更新，这三件事组合起来，就能让复杂的数据链路变得可感知。

对技术团队意味着什么

从技术角度看，异步公式的价值在于分层。

业务规则仍然可以体现在表格公式和单元格关系中；外部数据获取可以封装在自定义异步函数里；刷新入口可以由产品界面统一控制。这样一来，表格不必把所有逻辑都塞到页面事件里，也不必让后端一次性生成所有结果。

SpreadJS 的自定义异步函数支持默认显示值、异步返回结果和计算模式控制。开发团队可以根据业务需要决定函数是在重新计算时执行，还是按一定模式触发。对于需要批量刷新但不希望频繁请求的系统，这种控制很重要。

更重要的是，用户仍然在熟悉的表格里工作。公式、单元格、依赖关系没有被后台服务完全吞掉，业务人员理解和验证结果也更容易。

需要处理好失败和并发

异步刷新进入生产环境后，不能只考虑成功路径。

外部接口可能超时，网络可能失败，数据可能返回较慢，用户也可能连续点击刷新。系统需要处理加载提示、错误提示、重试、节流、旧请求覆盖新结果等问题。

还有一个常见需求是“刷新时间”。用户看到结果后，往往还想知道这些数据更新于什么时候。对实时性敏感的报表，可以在表格旁边显示最后刷新时间，或者对失败单元格给出更明确的状态。

这些不是 SpreadJS 自身要替业务决定的规则，而是团队在产品化时应该补上的体验设计。SpreadJS 提供的是异步公式和计算承接能力，业务系统需要在其上设计可靠的刷新策略。

写在最后

Web 表格正在从静态录入工具，变成连接业务系统的计算界面。

当数据来自外部服务时，用户最需要的不是看见复杂链路，而是拥有清晰控制：我什么时候刷新、哪些结果正在更新、更新后能不能信任。

SpreadJS 通过自定义异步函数、公式计算和依赖刷新能力，让表格可以承接实时数据、远程计算和批量更新场景。对需要做报价、库存、财务、风控、运营分析的系统来说，一键触发异步计算不是花哨功能，而是让动态数据进入表格工作流的一把钥匙。