WPS 表格能不能按颜色筛选并统计数据？这个问题要拆成两半回答才准确。筛选这一半，WPS 表格在桌面端已经原生支持，点开列标题右侧的下拉箭头就能看到按颜色筛选的入口；统计这一半，则没有对应的「一键按钮」，需要你借助 SUBTOTAL、AGGREGATE 或者辅助列，把可见行挑出来再算。把这两半分清楚，才不会在菜单里反复找一个并不存在的命令，也才不会把「找不到入口」直接误判成版本差异。
一、功能定位：颜色筛选筛的到底是什么
颜色筛选的本质，是按照单元格的显示格式过滤行。更准确地说，它读取的是单元格「直接设置」的填充色（背景色）或者字体颜色，然后把不匹配的行隐藏起来。这个过程不修改数据本身，也不修改任何单元格的格式，因此它天然是「视图层」的操作——这一点决定了后面所有的统计思路。
它有三条必须记住的边界。第一，条件格式生成的红色不算数：如果某个单元格是因为设置了条件格式规则才显示成红色，它的真实填充色仍然是「无填充」，颜色筛选的可选列表里不会出现这个红色。第二，颜色是精确比较的，同色系但色值不同的两种红会被当成两种颜色。第三，筛选结果会随数据变化而变化，它不是一份固化的结果集，改一个单元格的值，筛选结果可能立刻改变。
把颜色筛选和几个相邻功能放在一起看，各自的边界会更清楚。「查找」里的按格式查找，能定位到某个颜色的单元格，但它不会隐藏其他行；「条件格式」负责根据规则自动着色，回答的是「颜色从哪来」；「排序」里的按颜色排序，能把某种颜色排到最前面，但它同样不隐藏行。三者常常配合使用，职责却并不重叠——搞清楚谁负责产生颜色、谁负责挑出颜色，后面的操作路径就不会走偏。
二、桌面端最短可达路径
Windows 版：四步以内完成
Windows 桌面端的路径相对固定，可以按下面四步走：
- 选中数据区域中的任意一个单元格，或者直接选中整块区域。
- 在顶部功能区找到「数据」选项卡，点击其中的「筛选」按钮；部分版本在「开始」选项卡里也放了筛选入口。
- 点击目标列标题右侧出现的下拉箭头。
- 在弹出菜单里找到「按颜色筛选」这一组，选择「按单元格颜色」或「按字体颜色」，再点具体的色块。
为什么强调要先在「数据」选项卡里点「筛选」，而不是直接用右键菜单？因为自动筛选是一个「状态」，只有这个状态被打开之后，列标题上才会出现下拉箭头，颜色筛选的入口也才会随之出现。右键菜单里的相关命令，本质上也是开启或复用这个状态，只是入口更短。对新手来说，从「数据」选项卡进入更容易确认自己有没有漏掉某一步。
macOS 版：层级基本一致
macOS 版的入口在菜单栏：「数据」菜单 → 「筛选」，之后的交互与 Windows 版基本对齐，同样是在列标题下拉菜单里找到按颜色筛选的分组。经验性观察是，Mac 版的个别命令在措辞和位置上会与 Windows 版有细微差别，比如某些版本会把颜色筛选收在二级子菜单里。如果你一时找不到，可以先确认自动筛选是否已经打开，再逐一展开下拉菜单的各个分组。
需要说明的是，不同版本、不同发行渠道（个人版、专业版、以及各平台的移动版）在菜单命名上可能存在差异，本文描述的路径以截至当前最新版本的实际界面为准。若你的界面与描述不同，请以本机实际显示为准，并把差异记录下来，避免下次重复摸索。
替代入口与回退方案
除了列标题下拉菜单，部分版本还提供了基于当前单元格的快捷方式：右键某个已经填色的单元格，菜单里可能出现「按所选单元格的填充颜色筛选」一类的命令。这个入口的好处是不用先展开整个颜色列表，短板是它依赖你当前选中的单元格，选错了颜色就筛错了。
常见的失败分支有三种。第一种，下拉箭头存在，但菜单里没有「按颜色筛选」分组，这通常意味着该列没有任何直接设置的填充色或字体颜色，颜色筛选自然会隐藏。第二种，菜单里有分组，但可选色块是空的，原因基本同上。第三种，筛选后行数不对，需要检查是不是有单元格的颜色来自条件格式，而不是手工填充。
提示：想快速撤销一次颜色筛选，可以再次点击列标题下拉箭头，选择清除该列的筛选条件；也可以直接关闭整个自动筛选状态。若只是误操作，Ctrl+Z（macOS 为 Command+Z）通常也能退回上一步。不同版本对撤销筛选的粒度支持不完全一致，必要时以手动清除为准。
三、移动端：能做，但别指望全功能
Android 与 iOS 版 WPS 的表格界面，虽然同样具备筛选能力，但功能密度明显低于桌面端。经验性观察是，移动端的筛选更偏向「按值筛选」——比如按文本、按数字区间、按前若干项，颜色筛选的入口在不少版本里并不存在，或者藏在较深的层级中。常见的路径模式是：打开表格文件 → 找到「工具」或底部功能栏 → 「数据」→ 「筛选」，但具体措辞和层级因版本而异。
一个更现实的做法是分工：在桌面端完成颜色筛选和统计，把结果以「值」的形式落到表格里，再同步到移动端做只读查看。之所以不建议在手机上硬做颜色统计，是因为移动端既缺少稳定的自定义函数环境，也不方便核对颜色是否来自条件格式，出错之后排查成本很高。把重活留给桌面端，是投入产出比更高的选择。
四、筛选之后怎么统计：四条由快到准的路线
4.1 状态栏：最快的答案，但进不了单元格
筛选完成之后，最省事的统计方式就是看窗口底部的状态栏。在 WPS 表格里，选中一块区域后，状态栏默认会显示一些汇总信息；右键状态栏还可以勾选要显示的项目，常见的有平均值、计数、数值计数、最小值、最大值和求和。不同版本的默认项目不完全相同，以本机实际显示为准。
状态栏的特点是「只统计可见单元格」。为了验证这一点，可以做一个可复现的小实验：先在未筛选状态下选中整列金额，记下状态栏的求和结果；然后按某个颜色筛选，保持选中同一区域，观察求和结果是否变小。如果变小了，说明它忽略的是筛选隐藏掉的行，而不是把隐藏行也算进去。
它的边界也很明确：状态栏的数字是临时读数，不能写进单元格，不能参与其他公式，也不能成为图表的数据源。做临场核对可以，做正式报表不行。
4.2 SUBTOTAL：写进单元格的「可见行」统计
要把统计结果固化下来，SUBTOTAL 是首选。它的典型写法是：
这里的关键是第一个参数。9 代表求和，109 代表「只对可见单元格求和」，也就是在忽略筛选隐藏行的同时，还会忽略你手动隐藏的行。第二个参数是统计范围，尽量把范围写成固定区间，而不是整列引用，避免表格尾部不断被填充时出现意料之外的结果。
| 函数号 | 对应功能 |
|---|---|
| 1 / 101 | 平均值 |
| 2 / 102 | 数值计数 |
| 3 / 103 | 非空计数 |
| 4 / 104 | 最大值 |
| 5 / 105 | 最小值 |
| 9 / 109 | 求和 |
为什么不用 SUM？因为 SUM 会把被筛选隐藏的行也一并算进去，数字通常偏大，而且是那种「看不出错在哪」的偏大。很多「筛选后合计对不上」的问题，根因就是这里用了 SUM。把 9 换成 109 之后，同一个区域在筛选前后会呈现出完全不同的数字，这就是它该有的行为。
但也要说清它的边界：SUBTOTAL 并不理解颜色。它忽略的是「隐藏」这件事，而不是「红还是绿」。也就是说，它服务的是「先筛选、再统计」这个流程；如果你想跳过筛选直接按颜色统计，SUBTOTAL 帮不上忙。
4.3 AGGREGATE：数据里有错误值时更稳
当统计区域里混着 #DIV/0!、#N/A 之类的错误值，SUBTOTAL 会被错误值带偏，这时可以换成 AGGREGATE。它的写法是：
第二个参数是选项位。选项 5 表示忽略隐藏行，选项 7 表示忽略隐藏行和错误值。如果你的表格既做了筛选、又存在错误值，用 7 更省事。第一个参数 9 依然是求和，AGGREGATE 支持的功能号比 SUBTOTAL 更多，需要其他统计口径时可以在函数提示里查对应编号。
取舍上可以这样判断：表格干净、只是做了筛选，用 SUBTOTAL 就够；表格里存在预期之内的错误值，或者你希望统计口径更宽容，再上 AGGREGATE。没有必要为了「更强大」而统一换成 AGGREGATE，因为它的参数位对新手不够直观，协作时容易被后来的人改错。
4.4 辅助列：把颜色变成可计算的数据
如果你的判断条件本身就能写成公式，最稳的做法其实不是颜色筛选，而是加一列辅助列。示例：一张费用表，你把超预算的单元格手工标成了红色。与其按月按颜色筛选再统计，不如在辅助列里写一列「是否超预算」的判断公式，然后用 COUNTIF 或 COUNTIFS 直接统计。这样得到的数字不依赖人工涂色，也不依赖筛选状态，别人接手时一眼能看懂逻辑。
什么时候仍应保留颜色？当颜色承载的是「不适合写进字段的临时标记」时，比如几个人接力复核时用不同颜色标注「已确认」「待确认」「存疑」。这类标记本身是过程信息，不适合固化成列。此时颜色筛选加状态栏速读，反而是最轻的方案。
五、不筛选也想按颜色统计：三条技术路线
先解释一个常见疑惑：为什么没有「按颜色求和」这样的内置函数？因为公式引擎处理的是单元格的「值」，而颜色属于「格式」。格式可以随时被人手工改掉，如果函数依赖格式来算数，结果就会变得不可预测。这是所有主流电子表格软件的共同取舍，不是 WPS 独有的限制。
因此，想在「不筛选」的状态下统计颜色，本质上就要想办法把格式信息转成值信息。下面三条路线，复杂度依次上升，稳定性也依次变化。
5.1 宏表函数 GET.CELL
宏表函数是一类历史遗留函数，不能直接写在单元格里，必须先通过「公式」→「名称管理器」定义一个名称，再在单元格里引用这个名称。以判断填充色为例，可以在新建名称时把引用位置写成类似 =GET.CELL(38, A2) 的形式，其中 38 通常用于返回背景色的调色板索引，39 返回字体颜色的索引，63 返回填充色的 RGB 数值。这些编号属于宏表函数的既有约定，具体返回值请以你本机的实际结果为准。
提示：宏表函数的可用性受版本和设置影响。若整列返回 #NAME? 或类似错误，说明当前环境没有启用这类函数，请改用下面的宏方案，不要继续在公式层面硬试。
可复现的验证方法是：在一个空白表里，A2 填任意内容并手工涂成红色，然后在 B2 通过定义好的名称引用 A2，再给 A3 设置一条条件格式让它显示成红色，同样在 B3 引用。观察 B2 与 B3 的返回值是否不同——如果 B3 返回空或者与 B2 不一致，就印证了「条件格式的颜色不等于真实填充色」这条边界。
5.2 VBA 自定义函数
如果需要长期、反复地按颜色统计，写一个自定义函数更省事。需要注意的是，WPS 个人版默认不提供 VBA 运行环境，通常需要另外安装官方发布的宏支持组件，具体名称、版本与下载位置请以 WPS 官网的下载页为准，不要从第三方站点获取安装包。
下面是一个只做计数的示例函数，思路是把每个单元格的填充色与参考单元格逐一比对：
把这段代码放进宏编辑器的模块中保存，然后在单元格里写成 =CountByColor(A2:A1000, D1)，其中 D1 是一个已经涂成目标颜色的参考单元格。这样即使不做筛选，也能直接得到该颜色的单元格数量。把比对值从计数改成累加，就能得到按颜色求和。
它的边界在于性能：逐格循环的效率随区域大小线性下降。经验性观察是，几千行以内的区域通常可以接受，上万行时每次重算都会有明显的等待感。缓解办法是把范围收窄到真正需要的列，或者把结果用「粘贴为值」固化下来，避免每次打开文件都触发全量重算。
5.3 JS 宏路线
WPS 表格的宏编辑器支持 JavaScript，对于不熟悉 VBA 的用户，这条路线更容易上手。思路与 VBA 完全一致：遍历区域，比对颜色，把结果写回某个单元格。下面是一段示意代码：
这段代码只用于说明流程，具体对象名、方法与属性请以宏编辑器里实际提供的补全提示和官方开发文档为准。之所以强调这一点，是因为不同版本的宏接口存在差异，直接照抄一段未经核对的代码，很容易在第一步就报错。
5.4 工程上更稳的做法：辅助列
把上面三条路线放在一起比较，结论其实很朴素：宏能解决问题，但引入了新的依赖——文件里多了一段代码，协作方换一台电脑、换一个版本，可能就打不开或算不出。如果这张表需要长期维护、需要多人协作、需要跨平台查看，把颜色含义提前固化成辅助列，依然是成本最低、最不容易出事的方案。
判断标准可以这样定：一次性核对、用完即弃的表，用筛选加状态栏；周期性重复、需要留痕的表，用辅助列；只在个人机器上跑的临时分析，再考虑宏。顺序反过来做，往往会在协作环节付出更多返工成本。
六、例外与副作用：这些颜色统计不出来
- 条件格式产生的颜色：显示为红色，真实填充色却是「无填充」，颜色筛选列表里看不到它，宏读到的也是原始值。
- 渐变填充与图案填充：颜色本身不是单一色值，比较结果可能不符合直觉。
- 主题色与自定义色：同一屏上看起来一样，底层色值可能不同，精确比较时会被判为两种颜色。
- 合并单元格：只有左上角单元格持有内容和格式，其余位置为空，筛选和统计都容易出偏差。
- 手动隐藏与筛选隐藏：两者对 SUBTOTAL 的函数号选择、AGGREGATE 的选项位都有影响，混用会让合计数字对不上。
- 复制粘贴到其他程序：颜色可能被重新映射，导出的文件里颜色筛选结果与源文件不一致。
其中最容易踩的是第一条。很多人先在条件格式里设好「超过阈值变红」，再想按红色统计，结果怎么都筛不出来。这不是操作失误，而是方法用错了对象。正确做法是回到产生颜色的那条规则上，用同样的条件写一个统计公式，而不是去筛颜色。
七、故障排查：现象、原因、验证与处置
| 现象 | 可能原因 | 验证与处置 |
|---|---|---|
| 下拉菜单里没有「按颜色筛选」 | 该列没有直接设置的填充色或字体颜色；或自动筛选未开启 | 先确认筛选状态已打开，再检查目标单元格是否手工涂过色 |
| 按红色筛选后结果为空 | 红色来自条件格式，不是真实填充色 | 临时清除条件格式，观察是否出现手工颜色；或直接改用条件统计 |
| 筛选后合计偏大 | 统计公式用了 SUM 而非 SUBTOTAL(109) | 临时清空筛选，对比 SUM 与 SUBTOTAL 的结果差异 |
| 自定义函数返回错误值 | 宏环境未启用，或参考单元格为空 | 确认宏组件已安装，参考单元格确已填色 |
| 同一颜色被分成两类 | 两个单元格色值不同，只是肉眼相近 | 用取色工具或宏读出实际色值后再统一 |
排查顺序建议统一为「先看颜色来源，再看筛选状态，最后看统计公式」。这三步覆盖了绝大多数情况，也比逐个怀疑版本问题更有效率。若三步都正常，再考虑是否为文件本身损坏或版本兼容性问题，可以另存一份再试。
八、适用与不适用场景清单
适合用颜色筛选加可见行统计的场景：人工复核标记的临时表、一次性的数据清洗、几百到几千行规模的费用或库存核对、颜色含义在团队内已有共识的内部表格。这类场景的共同点是生命周期短、颜色含义稳定、不要求结果可复算。
不适合的场景同样清晰：需要长期留痕的报表、需要多人跨平台协作的台账、需要把统计结果接入图表或下游系统的表、颜色由条件格式自动生成且规则还会调整的表。这些场景应当优先考虑辅助列加 COUNTIF/SUMIF，或者干脆在数据源头记录状态字段。
九、最佳实践检查表
- 开始筛选前，先确认目标列的颜色是手工设置的，而不是条件格式生成的。
- 统计单元格一律使用 SUBTOTAL(109) 或 AGGREGATE，不要用裸 SUM。
- 把统计范围写成固定区间，不要整列引用。
- 颜色含义超过三种、或者需要长期维护时，改用辅助列。
- 使用宏方案时，先在小区域试跑，确认返回值正确再扩大范围。
- 宏方案上线前，把结果粘贴为值留一份快照，便于核对。
- 把筛选和统计的操作步骤写在表格的说明页里，方便交接。
十、常见问题
WPS 表格可以按颜色筛选吗？
筛选后求和为什么还是全部数据的和？
条件格式标红的单元格能按颜色筛选出来吗？
有没有不筛选就能按颜色统计的内置函数？
手机版 WPS 能做颜色筛选吗？
十一、小结：把颜色当标记，不要当数据源
回到最初的问题：WPS 表格支持按颜色筛选，这件事是确定的；按颜色统计则需要你自己接一段——筛选配合 SUBTOTAL 是最短的路径，辅助列是工程上最稳的路径，宏则适合个人临时分析。三条路的共同前提是，那些颜色必须是手工设置的，条件格式生成的颜色不在此列。
下一步可以这样动手：先在一张有代表性的小表上跑通「按颜色筛选 → SUBTOTAL 求和 → 状态栏核对」这一整条链路，确认数字对得上；再把同样的做法套到真实数据上。如果发现颜色含义已经复杂到需要解释，那就是切换到辅助列的信号了。把颜色留给「看」，把状态留给「算」，这张表才能既好看又可靠。