产品筛选空结果怎样建模：分开零匹配、资料缺失与请求异常

产品筛选接口返回一个空数组，前端便显示“暂无产品”，是一个容易掩盖故障的实现。空数组可能表示一次有效查询没有匹配，也可能是异常被兜底成了空数组。资料缺失则是另一个维度：没有填写属性的产品，不能被当作明确不满足条件。

本文给出一份接口与前端状态的设计样例。核心原则是：先确认请求有效，再解释查询结果；资料覆盖度单独表达；已选条件在重试和修改时保持可复核。示例只使用虚构数据，不对应已上线客户系统。

1. 先明确三类信息的责任边界

传输与执行状态回答“请求有没有正常完成”。连接异常、非预期响应或无法解析的数据都不应进入正常空结果分支。

查询结果回答“在已确认的数据范围内，有没有完全匹配项”。只有成功完成的有效查询，才可以根据结果数量显示有结果或零结果。

资料覆盖度回答“本次筛选依赖的属性是否完整”。它可以与有结果、零结果同时存在，不宜混成一个互斥状态。例如已确认的产品中匹配到两个型号，同时有三个型号的材料属性尚待核准。前端可以显示两个确认结果，并说明覆盖范围不完整，不能宣称穷尽了全部产品。

参数是否合法还要在查询前独立处理。单位、范围上下限和允许的字段由接口契约约定；非法参数应返回可理解的校验信息，不能用零结果掩盖。

2. 让前端只根据明确字段进入空结果分支

以下是一个纯函数样例，用于说明响应结构如何影响显示状态。示例约定每次成功响应都含 items 数组，以及完整性字段 coverage。生产接口还需补充鉴权、字段校验和监控；这个函数不代表完整请求层。

function toFilterView(response, filters) {
  const selected = { ...filters };
  const failed = () => ({ state: 'error', selected, items: [] });
  if (!response || response.ok !== true) return failed();
  if (!Array.isArray(response.items)) return failed();
  if (!['complete', 'partial'].includes(response.coverage)) return failed();
  return {
    state: response.items.length > 0 ? 'results' : 'empty',
    selected,
    items: response.items,
    coverage: response.coverage
  };
}

这里的 ok 是本文自定义的业务响应字段，不是对某个浏览器响应对象的直接操作。请求层负责处理超时、解析异常和取消等情况，保证交给函数的输入符合约定。items 内单条记录是否合法，也应在请求层或单独校验器检查。

coverage 为 partial 时，即使 state 为 empty，也只表示“在已确认资料中没有匹配”，不表示企业没有对应产品。旧接口若没有覆盖度信息，应先明确缺省含义或补充契约，不能在前端默认为 complete。

3. 用四组虚构输入检查分支

把上面的函数与下面断言放在同一脚本中，可核对最基本的状态分支。断言仅覆盖本文样例；不代表浏览器交互、网络故障或生产集成已经通过验收。

const filters = { material: 'TEST-MATERIAL' };
console.assert(toFilterView({ ok: true, items: [], coverage: 'complete' }, filters).state === 'empty');
console.assert(toFilterView({ ok: false }, filters).state === 'error');
console.assert(toFilterView({ ok: true, items: null, coverage: 'complete' }, filters).state === 'error');
const partial = toFilterView({ ok: true, items: [{ id: 'TEST-1' }], coverage: 'partial' }, filters);
console.assert(partial.state === 'results' && partial.coverage === 'partial');
console.assert(partial.selected !== filters && partial.selected.material === filters.material);

selected 采用浅拷贝，所以样例只适合当前这些字符串条件。若实际条件含嵌套对象或数组，应按数据结构明确复制与更新规则。不要把样例的浅拷贝描述成对任意条件的完整隔离。

4. 还要处理并发和重试，而不是只处理数组

客户先选材料A，随后改成材料B，A的旧请求可能更晚返回。页面应通过请求序号等机制识别过期响应，不能让旧响应覆盖新选择。取消旧请求可以减少浪费，但仍需核对返回结果属于哪一组条件。

重试时保留当前选择，明确正在加载；新条件开始查询后，旧结果若仍显示，应清楚标识更新状态，不能让客户把它误解成新条件的匹配。页面返回、手机筛选面板展开以及取消单项，都应纳入复测。

建议交付一张状态表：初始、加载、有结果、零结果、校验不通过、请求异常；每个状态分别记录条件是否保留、提示内容及可用操作。资料完整性作为附加字段单独核对。

5. 从筛选结果进入需求表单时再次确认

需求表单可以带入已选条件和来源产品系列，先展示给客户检查，再由客户提交。服务端仍需按允许字段和业务规则校验，不能直接信任页面传来的型号、参数或替代关系。

不要自动降低承压、温度、接口等关键条件以换取一个非空结果。近似型号比较若被纳入范围，需要企业技术人员确认可比较维度，并明确展示差异。资料不足时应保留待核对状态。

需求记录和通知能力另行验收：是否存档、通知哪些信息、失败由谁接手，取决于现有系统。用带TEST标识的虚构数据和授权测试收件方式，分别核对记录与通知。日志只保留定位故障所需字段，不把客户联系方式、附件内容或访问凭据作为公开调试材料。

6. 交付边界、工作量与常见问题

一份可交接的交付物应包含接口契约、覆盖度口径、状态表、虚构样本、实际复测记录和资料维护负责人。工作量受参数维度、单位转换、多语言、历史资料清理和旧接口能力影响。完整性统计、近似比较与后台补核界面是不同范围，应单独说明；代码样例没有替这些能力作出交付承诺。

问：HTTP请求成功，就能展示“无匹配”吗？

不能。还应核对业务状态、结构与字段有效性。无效响应和解析失败应进入异常处理，不能被转换成正常零结果。

问：coverage不完整时，是否应该隐藏全部结果？

不一定。可以展示已确认资料中的匹配项，并说明覆盖范围。不能猜测未知参数，也不能把现有结果称为完整产品清单。

问：重试时把条件清空更省事，是否可行？

这会丢失客户已经形成的需求。建议保留当前条件并提供主动清空入口，同时防止旧请求覆盖新状态。

资料说明：本文为城池设计的开发方法分享，2026年10月16日，经AI辅助整理并审校。证据边界：没有可公开核验的同类客户案例、生产故障或转化数据。代码只验证虚构输入的局部分支，不代表任何客户系统已具备本文所述能力。