如何在WPS表格中按单元格颜色筛选并统计数量？

从一份被标黄的台账说起

季度对账时，很多团队会拿到这样一张表：几千行明细里，同事用手动填充色把「待复核」标成浅黄、把「已退回」标成浅红，又把几处异常金额的字体改成红色。等到要写说明材料时，问题来了——每种颜色到底有多少行？这时候就需要在WPS表格中按单元格颜色筛选并统计数量。

但这个需求背后往往藏着一个更棘手的问题：颜色是给人看的，不是给机器看的。它不进入单元格的值，不受公式管辖，也很难在各种流转环节中稳定保留。所以本文除了给出操作路径，还会花相当篇幅讨论一件事——什么时候颜色筛选够用，什么时候不该把它当作唯一依据，以及如何把颜色标记转成可审计、可留存的数据结构。

阅读提示：本文涉及的所有界面路径均以截至当前的最新版本为例。WPS 桌面端、移动端与在线版的界面条目存在差异，具体以你实际安装的版本为准；遇到不一致时，请以「能否完成同一目标」为准绳，而不必强求按钮文字完全一致。

功能定位：颜色筛选究竟解决什么问题

WPS 表格的筛选功能里提供了一个「按颜色筛选」入口，它做的是这样一件事：扫描你指定的那一列，把该列中实际出现过的填充颜色和字体颜色收集成一份候选清单，你点选某个颜色，表格就把该列中拥有这个颜色的行筛出来。它的价值在于「反向查询」——你知道颜色代表什么含义，但不知道哪些行被标了，于是用颜色去找行。

需要先明确它的能力边界。第一，它只作用于当前列，候选清单只包含这一列里出现过的颜色，跨列的颜色组合无法直接筛。第二，它识别的是「单元格格式」层面的颜色，而不是「看上去是什么颜色」。第三，候选清单里通常不会出现条件格式动态生成的颜色——这一点后文会单独展开。理解了这三条，你才不会在操作到一半时觉得「功能坏了」。

颜色筛选与条件格式的区别

这是最容易被混淆的一处。手动填充颜色，是你直接给单元格设置了一个静态格式，「这个格子是黄的」被写进了单元格的属性里。条件格式则相反，它存的是一条规则，比如「当 D 列数值小于 0 时显示红底」，单元格在屏幕上变红只是规则运行出来的结果。

经验性观察：在多数版本中，条件格式生成的颜色不会进入「按颜色筛选」的候选清单，因为筛选读取的是静态格式属性，而条件格式的颜色是渲染阶段的产物。如果你的表格整列都是条件格式上的色，点开筛选下拉却发现颜色清单是空的，这不是故障，而是设计使然。

可复现的验证方法：新建一张空白表，A1:A5 填入 1 到 5；选中 A1:A5 设置条件格式为「数值小于 3 时填充绿色」；再选中 A1 手动填充一次绿色；然后对 A 列启用筛选并点开「按颜色筛选」。预期可观测到的现象是：候选颜色清单里通常只出现你手动填充的那一个绿色，条件格式引发的绿色往往不出现。这个实验可以作为你判断当前版本行为的基准。

颜色筛选与「查找」的分工

很多人不知道，WPS 表格的查找替换对话框里也有一条按格式查找的路径：打开查找，展开更多选项，通过「格式」按钮选择「从单元格选取格式」，再去吸一下目标颜色的格子，最后点「查找全部」，对话框下方会列出所有匹配项。这条路适合「只想知道有多少个、分别是哪些」的场景，优点是不动原表结构，缺点是结果不能直接参与后续计算。

所以两者是有分工的：需要临时定位、核对散落的彩色单元格，用查找；需要把某个颜色的行整体拿出来做统计、复制、导出，用筛选。至于具体的按钮文字与层级，桌面端与移动端的表现并不一致，下面单独说明。

版本与平台差异：先确认你手上是哪一套

同一个功能在不同端的完整度差别不小。桌面端（Windows、macOS）是能力最全的一档，颜色筛选、条件格式、SUBTOTAL 函数、状态栏统计都能用。移动端（Android、iOS）优先保证查看与轻量编辑，筛选本身可用，但「按颜色筛选」这个入口在多数版本中不一定暴露出来，或者被收进了更深的层级。在线表格介于两者之间，具体取决于你使用的是哪一种在线形态。

对这种差异，务实的态度是：把「标色」和「筛色」这类结构性操作放在桌面端完成，把移动端当作查阅端。如果你经常在手机上被要求「把黄色的那些行数一下」，建议在桌面端预先加一个辅助列把状态固化下来，手机端只要看这个辅助列就够了——这也是本文反复推荐的做法。

这张表的目的不是给你一份精确的功能清单，而是建立预期：不要假设手机上能做到桌面端的全部事情，也不要在桌面端明明能解决的问题上绕远路。上表若与你的实际界面冲突，以实际界面为准，并把差异记录下来，作为团队内部的统一口径。

操作路径：桌面端的完整三步法

下面这条路径是在桌面端完成「按颜色筛选 + 统计数量」的最短走法。为了让步骤可复用，我把它拆成三步：先固定数据结构，再筛，最后数。

第一步：让数据区具备表头与连续区域

选中数据区内的任意一个单元格，在「开始」选项卡或「数据」选项卡中找到「筛选」并启用（很多用户习惯记快捷键，它的作用等价）。这一步会自动把首行识别为标题行，并在每一列标题上挂一个下拉箭头。如果你的表中间有空行、合并单元格，或者标题行不完整，筛选的范围就可能判错，先把这些结构问题清掉，比事后排查便宜得多。

为什么强调这一步？因为颜色筛选是「列级」操作。你点哪一个下拉箭头，就只能在那一列的颜色集合里选。如果颜色散落在好几列里，你需要先在脑子里明确「以哪一列为准」，否则筛出来的数量并不是你以为的那个数量。

第二步：打开下拉箭头，选择按颜色筛选

点击目标列标题上的下拉箭头，菜单中会出现「按颜色筛选」这一项，展开后分成两组：按填充颜色、按字体颜色。清单里列出的就是你这一列中实际出现过的颜色样本，点其中一个，表格立即把该列中带有这个颜色的行筛出来，其余行被暂时隐藏。

这里有个容易踩的细节：如果你在标色时用了「深浅不同的两种黄」，它们会被视为两种不同的颜色，清单里就是两项。人眼觉得「都是黄的」，程序认为是两个值。所以团队协作时最好约定一套固定的色板，标色前统一下标准，这比筛的时候逐个勾选要省事得多。

第三步：读出数量——三条路任选其一

筛选完成后，数量其实已经在那里了，只是藏在三个不同的地方。最省事的是看状态栏：选中该列的数据区域（不含标题行），状态栏会显示计数结果。如果状态栏没显示想要的项目，在状态栏上单击右键，勾选你需要显示的项目，例如计数、数值计数、求和。

第二条路是用函数把数量固定成可见的值。在空白单元格里输入聚合函数，对目标列做可见行计数，筛选条件一变，这个数字就跟着变，适合做报表抬头。第三条路是拆解颜色——用辅助列把状态写下来，再用条件统计函数计数。三条路各有适用场合，下一节展开对比。

三条计数路径的取舍

状态栏、聚合函数、辅助列，这三者不是「哪个更好」的问题，而是「哪个更符合你现在要做的事」。下面按使用场景来区分。

经验性观察：真正让统计变麻烦的，从来不是「怎么数」，而是「数的东西会不会变」。颜色筛选的候选清单是随数据动态生成的，今天有四种颜色，明天可能变成六种；而辅助列里的状态值是稳定的文本，不会因为有人随手改了个颜色就改变统计口径。这也是本文把辅助列列为推荐做法的原因。

聚合函数的用法要点

WPS 表格支持聚合函数家族，其中做计数时常用的有两种编号：一种统计非空单元格，另一种在此基础上忽略被隐藏的行。把两者放进同一个公式表里对比，你会发现区别只在第一个参数。当你的隐藏来源是筛选时，基础编号通常已经能满足；当隐藏来源是手动隐藏整行时，需要用带忽略隐藏的那种编号。

实践中的常见错误是把聚合函数写在了标题行上，导致筛选一变、公式所在行也被隐藏，数字跟着消失。稳妥的位置是放在数据区之外，比如表格右侧留一列「统计区」，或者干脆放到另一个工作表里。放在外面还有一个好处：打印时不会被筛选动作影响布局。

辅助列方案：把颜色翻译成可计算的值

现在把视角切到合规与数据留存。前面说过，颜色是一种隐式标记，它不进入单元格的值，因此无法被公式直接引用，也难以在导出、转换、跨程序流转中稳定保留。如果你做的只是一次性核对，这不是问题；但如果这张表要交接给下一个人、要作为材料留档、要在几个月后还能复现结论，就必须做一件事：把颜色代表的含义，落成真正的字段。

具体做法是在数据区末尾新增一列，命名为「状态」或「标记类型」，用文本值表达含义，例如「待复核」「已退回」「异常金额」。录入时用数据有效性的下拉列表来控制取值范围，避免出现五花八门的写法。颜色则退居二线：用条件格式根据这一列的文本值自动上色——注意，这里的颜色是派生出来的，它的源头是文本值，而不是你手动涂的。

这个改造成本很低，通常十几分钟就能完成，但它把一张「只有当事人看得懂」的表，变成了一张「任何人拿到都能复核」的表。在审计、交接、跨部门协作这三类场景里，这个差别是决定性的。

一个小规模示例

假设有一张三百行左右的费用明细表，原本的标记方式是在备注列手动涂色：浅黄表示「发票待补」，浅红表示「金额待核」。财务同事需要提交一份说明，写明各有多少条。按颜色筛选的做法是：筛一次浅黄，读一次状态栏数字；筛一次浅红，再读一次；把两个数字抄进说明文档。这个流程本身没问题，但一周后如果有人补充了几行新数据，说明文档里的数字就与表脱节了，而且没人知道当初是怎么数出来的。

改成辅助列方案后：新增「状态」列，下拉选择「发票待补」或「金额待核」；条件格式根据状态列自动上同一种颜色，视觉上与原表一致；在统计区用条件统计函数按文本计数，得到两个可以随数据自动更新的数字。说明文档里直接引用这两个数字，更新表格后数字自动同步，任何人都能点进公式看清楚它是怎么算出来的。这就是「可审计」在表格层面的具体含义。

兼容性：颜色在流转中会发生什么

要让颜色承担统计职责，就必须回答一个前置问题：它在你接下来的每一步流转中，还在不在？下面按常见的流转环节逐一说明，并给出验证方法。

表格里写「通常」而不是「一定」，是因为这些行为受版本、导出方式、目标程序等多重因素影响，无法给出一个放之四海皆准的结论。可复现的验证方法：取一张有颜色的样例表，按上面五种方式各处理一份，逐一打开并观察颜色是否还在、按颜色筛选的候选清单里还剩几项。这个测试做一次，就能建立起你对当前环境的准确预期。

跨平台操作要点：移动端怎么处理

移动端的定位是「快」和「看」。在 Android 与 iOS 上，WPS 的表格组件可以打开文件、查看数据、做基础编辑，筛选能力也具备，但按颜色筛选这个入口在不同版本中的呈现方式差别较大，有时会被收进更深的菜单层级，有时干脆不出现。与其记住某个具体路径，不如记住判断方法：点开列标题的筛选入口后，看菜单里有没有与颜色相关的分组；没有的话，说明这个版本不提供该能力。

因此在移动端的实用策略是「看状态列，不看颜色」。如果按照前文建议已经建立了辅助列，那么在手机上你只需要用普通筛选按文本值筛一下，数量就能从状态栏或单元格里的公式读到，完全绕开了颜色识别的兼容性问题。这也是为什么辅助列方案在混合办公环境下回报特别高。

进阶路径：用宏表函数读取填充色

经验性观察：在部分桌面版本中，存在通过名称管理器调用宏表函数、从而读取某个单元格填充色编号的做法。它的思路是先定义一个名称，名称的公式指向目标单元格并取出其颜色属性，然后在单元格里引用这个名称，得到一个代表颜色的编号，再用条件统计类函数按编号计数。

这条路能解决「颜色变了要重新筛」的问题，但它有明显的适用边界。第一，它对环境的依赖较强，不同版本、不同平台的支持情况不一致，移动端与在线版通常不可用。第二，这类公式往往不会随格式变化自动重算，修改颜色后可能需要手动触发一次重算才能刷新结果。第三，它对使用者有门槛，接手的人未必看得懂名称管理器里那条公式。

可复现的验证方法：在桌面端新建一张小表，按上述思路定义一个名称，引用到单元格里观察是否能取到数值；改变目标单元格的填充色，观察引用值是否随之变化、是否需要手动重算。如果这三步都能顺利跑通，说明你的环境支持；任何一步不成立，就果断回到辅助列方案，不要在一条不稳定的路上投入太多。

故障排查：现象、原因、验证与处置

下面按「先看现象」的方式组织，每一条都给出验证与处置。这类问题的共同特点是：看起来像功能失效，实际上多半是前提条件没满足。

现象一：筛选下拉里找不到颜色分组

先确认这一列里是否真的存在手动设置的填充色或字体色——如果整列的颜色都来自条件格式，候选清单为空是符合预期的。验证方法是随便挑一个格子手动填充一次再点开下拉，看是否出现。若仍不出现，检查当前设备的版本与平台，移动端与在线版不提供该入口属于常见情况。处置：改用查找定位，或直接采用辅助列方案。

现象二：筛出来的行数比肉眼估计的多或少

最常见的原因是「目测同色、实际异色」。深浅不同的两种黄、由不同来源复制粘贴带入的近似色，都会被当作不同的颜色。验证方法是展开颜色候选清单，看里面到底有几项。处置：统一色板后重新标色，或者在辅助列里把状态写清楚，从此不再依赖颜色。

另一个原因是筛选区域的范围判断有误，比如数据区中间存在空行，导致筛选只覆盖了一部分。验证方法是临时取消筛选，观察下拉箭头覆盖的列范围是否完整。处置：清理空行与合并单元格后重新启用筛选。

现象三：状态栏没有显示计数

多数情况下是状态栏的显示项没勾选，或者当前没有选中任何单元格。验证方法是选中一片明确有内容的区域，观察状态栏是否出现任何数值。处置：在状态栏上单击右键勾选所需项目；若选中区域里全是文本，注意「计数」与「数值计数」两个项目的含义差异，前者统计非空，后者只统计数字。

现象四：更新数据后统计数字没有跟着变

如果数字来自状态栏，它本来就不会跟着变，因为它不是公式。如果数字来自聚合函数，检查是否需要手动重算，以及筛选条件是否已经改变。如果数字来自依赖颜色属性的取色公式，这一类的重算行为尤其容易滞后。处置：把统计口径从「颜色」迁移到「状态列」，是根治这一类问题的唯一稳定方案。

适用与不适用：一张准入清单

颜色筛选不是坏功能，只是它的适用范围比很多人以为的要窄。下面用「适合」与「不适合」两组条件来划界，你可以拿自己的场景逐条对照。

• 适合：一次性核对，数完即用，不进入任何留档流程。
• 适合：数据量在几百到几千行、颜色种类不超过三四种、由同一人在同一台设备上操作。
• 适合：颜色只是辅助视觉线索，真正的状态已经写在某一列里。
• 不适合：结果要写进对外材料、要被第三方复核、要在几个月后被重新验证。
• 不适合：多人协作标色，且没有统一色板约定。
• 不适合：数据需要导出、转换、跨程序流转。
• 不适合：主要操作发生在移动端或在线版。

如果你发现自己的场景有一半落在「不适合」里，那答案其实已经很清楚了：这次可以用颜色筛选应急，但下一版表格一定要把状态写成字段。这不是为了追求形式上的规范，而是因为一旦进入协作与留存环节，不可追溯的标记迟早会变成一笔说不清的账。

最佳实践检查表

把前面的讨论压缩成一份可以贴在工位上的清单。每次要在表格里用颜色表达含义之前，快速过一遍。

1. 先问一句：这个颜色要不要被统计？要，就立刻建辅助列。
2. 全表统一色板，最多三到四种含义，每种含义配一个固定的文本值。
3. 颜色由条件格式根据文本值派生，而不是手动涂。
4. 统计数字用条件统计函数算，放在数据区之外，避免被筛选隐藏。
5. 涉及合并、跨行、多列颜色时，先拆成单列状态再统计。
6. 导出任何纯文本类格式之前，确认状态列已经写好。
7. 移动端只做查看与轻量筛选，结构化操作回到桌面端。
8. 交接时用一句话说明「状态列是准的，颜色只是显示」，并写进表头附近的说明单元格。

这份清单里，真正起作用的是第一条。绝大多数后续麻烦，都源于「当初只是随手涂个颜色，没想到后来要数」。把判断提前到涂色之前，成本几乎为零。

验证与观测：如何确认结论仍然成立

本文涉及的多处行为都标注了「通常」「经验性观察」，原因是这些表现会随版本与平台变化。与其记住结论，不如掌握验证方法。建议在正式使用前花十分钟做一次基线测试。

把这个测试的结果记在团队文档里，比任何一篇教程都更贴合你的实际环境。半年后如果换版本，重跑一遍即可，成本很低。

风险与边界：什么时候不该用颜色

有三类场景应当明确避开颜色方案。第一类是涉及金额认定与责任划分的表格——统计口径必须能被第三方独立复算，颜色做不到这一点。第二类是存在多轮修改、需要追溯谁改了什么的数据——颜色不携带作者与时间信息，无法支撑追溯。第三类是需要在不同系统之间流转的数据——颜色在多数交换格式里没有对应字段。

这三类场景的共同点，是「结论需要被别人检验」。检验的前提是，对方能从原始数据出发，用同一套规则算出同一个结果。凡是做不到这一点的表达方式，无论看起来多么直观，都不适合承担这类职责。颜色恰好就是这样的表达方式。

常见问题

结语：把颜色降级为显示，把状态升级为数据

回到最初那张被标黄的台账。用WPS表格的按颜色筛选，你可以在几分钟内把每种颜色的行数读出来，步骤清晰、门槛极低，应急场景下完全够用。但只要这份结论需要交给别人、需要留档、需要在一段时间后被重新验证，颜色就会暴露出它的根本短板——它不进入数据，因此无法被复核。

所以更值得采取的下一步，是给这张表加一列状态字段，把颜色改成由条件格式派生，再把统计口径从「筛颜色」切换到「按值计数」。这三步做完，你会得到一张任何人拿到都能独立复算的表，而颜色依然留在那里，继续承担它最擅长的工作：让异常一眼可见。

如果你现在就有一张需要处理的表，建议的动手顺序是：先花十分钟跑一遍前文的基线测试，确认当前版本的颜色筛选行为；再决定这次是临时筛一次，还是顺手把状态列建起来；最后把测试结论和表头说明一起写进文件，让下一个打开它的人不需要再问一遍同样的问题。