功能定位：为什么“忽略隐藏行”会成为刚需

在 WPS 表格里做“累计求和”时，只要开启筛选或手动隐藏行，传统 SUM 会把隐藏值一并算入，小计、仪表盘、动态图表瞬间失真。关键词“WPS表格如何按条件累计求和并忽略隐藏行”要解决的，正是既要条件判断，又要视觉可见行才参与运算的双重约束。先厘清这一点，你就能在 SUBTOTAL、AGGREGATE、动态数组三条路线里快速对号入座，而不是把函数挨个试个遍。

方案对比：SUBTOTAL、AGGREGATE 与动态数组的取舍

SUBTOTAL：最轻量、兼容性最好

SUBTOTAL 代码 109 天生忽略手动隐藏行，但对“筛选隐藏”和“条件判断”仍需再套一层筛选器。优点是任何版本都有，缺点是条件逻辑只能依赖辅助列或当前筛选状态，无法一次性写死。

AGGREGATE：在条件列直接写公式，无需辅助列

AGGREGATE(109,5,求和区域) 同样忽略隐藏行，且支持数组运算，可把条件写进单个公式。代价是文件体积略增；经验性观察：数据过 5 万行时，重算耗时比 SUBTOTAL 高 15%—20%，仍在“数十秒”可接受区间。

动态数组（FILTER+SCAN）：写法最直观，但版本受限

截至当前最新版，Windows 桌面端已推送 FILTER/SCAN，Android 移动端尚未完整支持。若团队混用多平台，建议优先 SUBTOTAL 或 AGGREGATE，避免公式在手机上显示 #NAME?。

提示

文件需交给外部客户且版本未知时，优先 SUBTOTAL+辅助列，兼容性>性能。

决策树：三步选出最低成本方案

是否必须“一个公式写完”？
- 是 → 继续看 2；
- 否 → 用 SUBTOTAL+辅助列，结束。
数据量是否超过 5 万行且频繁重算？
- 是 → SUBTOTAL+辅助列，牺牲简洁换性能；
- 否 → 继续看 3。
接收端是否可能用旧版 WPS 或移动端？
- 是 → SUBTOTAL；
- 否 → AGGREGATE 或动态数组。

操作路径：Windows 桌面端最短步骤

SUBTOTAL+辅助列（兼容最强）

在数据区域右侧插入“条件标记”列，公式示例：=--(B2>="2026-01-01")，结果 1 为满足条件，0 为不满足。
启用“筛选”：开始 → 筛选（或 Ctrl+Shift+L）。
在筛选下拉中勾选条件标记=1，此时视觉可见行即为目标。
在需要显示小计的单元格输入：=SUBTOTAL(109,C2:C10000)，其中 C 列为待求和字段。109 代表忽略隐藏行求和。
若后续需要换条件，只需改条件列公式或重新勾选筛选，SUBTOTAL 会自动跟随。

AGGREGATE 单公式（无需辅助列）

假设 A 列为日期，B 列为销售额，需求：对 2026-01-01 之后的可见行累计求和。
在结果单元格输入：
=AGGREGATE(109,5,B:B/((A:A>=DATE(2026,1,1))))
按下 Enter 后，WPS 会自动忽略被隐藏的行，同时只累加日期符合条件且可见的销售额。

警告

AGGREGATE 的数组运算在整列引用时可能触发“整列计算”性能警告，建议把 B:B 改成实际区域如 B2:B10000。

移动端差异：Android 与 iOS 实测

在 Android 平板上打开同一文件，SUBTOTAL 公式可正常重算，但“手动隐藏行”手势入口被折叠到“行列”→“隐藏与取消隐藏”；iOS 端路径更短：长按行号 → 隐藏。AGGREGATE 在两端均能识别，但编辑公式时缺少函数提示，需要完整手工输入，容易拼错参数。

验证方法：如何确认“隐藏行真的被忽略”

在空白列建公式 =ROW()，向下填充，得到行号。
手动隐藏第 5 行，观察 SUBTOTAL(109,行号列) 结果是否比 SUM 少 5。
再启用筛选，把某条件去掉，观察结果是否进一步减少。若两次都正确，即证明隐藏行被忽略。

常见例外：这些“隐藏”SUBTOTAL 并不忽略

使用“分组”折叠（数据 → 分组）产生的隐藏，SUBTOTAL 仍会算入；此时需要 AGGREGATE(109,7,…) 才能忽略。
通过“筛选”隐藏的行，SUBTOTAL 109 会忽略；但若用 9 而非 109，则不会忽略。
条件格式或手动字体颜色设为白色，视觉上“看不见”，但行并未隐藏，仍会被计算。

性能与成本：什么时候不该用 AGGREGATE

经验性观察：当数据量超过 10 万行且公式数量超过 200 个时，AGGREGATE 的数组运算会导致文件打开时间从“亚秒级”延长到“数十秒”，并触发 CPU 单核满载。此时回退到 SUBTOTAL+辅助列，可把打开时间缩短约一半，且自动计算模式不再卡顿。

协作流程：如何让别人不破坏你的“隐藏”逻辑

多人同时维护表格时，最常见事故是“取消隐藏”或“复制整行”导致条件列断裂。建议把条件列设为灰色填充，并在工作表保护中锁定公式区域：审阅 → 保护工作表 → 允许“使用筛选”但禁止“格式化列”。这样同事仍能筛选，却无法误删条件标记。

最佳实践清单：交付前 5 秒自检

隐藏任意一行，看小计是否变化；若无变化，说明公式用了 9 而非 109，立即修正。
把文件另存为 .et 与 .xlsx 双格式，用 WPS 与 Excel 各开一次，确认 AGGREGATE 无 #NAME?。
在状态栏右键勾选“求和”，手动框选可见区域，对比状态栏结果与公式结果，误差应为 0。
把筛选下拉全选→确定，再恢复默认条件，观察公式是否自动刷新；若需按 F9 才变，说明计算选项被设为“手动”，应调回“自动”。
文件→属性→统计，若公式数>200 且行数>5 万，记录打开耗时作为基线，供后续版本对比。

FAQ：3 个高频疑问一次说清

为什么 SUBTOTAL 有时不忽略筛选隐藏？

大概率把函数代号写成 9 而非 109；9 仅忽略手动隐藏，109 才同时忽略筛选隐藏。

AGGREGATE 能否替代所有 SUMIFS？

只能替代“条件+忽略隐藏”场景；若无需忽略隐藏，SUMIFS 性能更好。

文件发到手机后公式报错怎么办？

优先用 SUBTOTAL，避免动态数组；若已用 AGGREGATE，确保手机端升级到截至当前的最新版本。

收尾：下一步行动

先根据数据量级和协作环境，用本文决策树锁定 SUBTOTAL 或 AGGREGATE；按最短路径实操一次后，用“隐藏行验证法”确认结果；最后把最佳实践清单贴在工作簿首页，团队任何人都能 5 秒自检。这样，WPS表格按条件累计求和并忽略隐藏行就不再是黑盒，而是可复现、可交接、可审计的标准动作。

WPS表格如何按条件累计求和并忽略隐藏行？