如何结合`archiveFilters.md`获取的筛选条件，应用到`archive/list`的自定义筛选参数中？
在安企CMS中，高效地管理和展示网站内容是提升用户体验的关键。当内容量日益增长时，提供灵活的筛选功能，帮助访客快速找到所需信息，显得尤为重要。安企CMS为此提供了强大的API接口支持，通过巧妙地结合archive/filters接口获取的筛选条件，并将其应用到archive/list接口的自定义筛选参数中，我们可以构建出极其实用的内容筛选功能。
理解安企CMS的筛选机制
安企CMS的文档筛选能力，主要体现在两个核心API接口的协同工作上：一个是用于发现网站上可用的筛选条件（/api/archive/filters），另一个则是应用这些条件来获取具体文档列表（/api/archive/list）。这两者之间存在着紧密的联系，通常我们会先通过第一个接口了解当前内容模型下有哪些可筛选的维度，然后再将用户的选择转化为第二个接口能够识别的参数，从而精准地提取所需内容。
在使用这两个接口时，一个至关重要的参数是模型ID（moduleId）。在安企CMS中，不同的内容类型（比如文章、产品、案例等）都对应着一个特定的内容模型，每个模型可能有其独特的筛选字段。因此，在进行任何筛选操作之前，明确你想要筛选的是哪个模型下的文档是第一步。
获取可用的筛选条件 (/api/archive/filters)
想象一下，你正在为你的产品展示页面设计一个筛选器，用户希望能够按照“城市”或“学历”来查找相关产品。这时，你就需要知道安企CMS为你的“产品”模型（假设其moduleId是1）配置了哪些可供筛选的字段和选项。
通过调用/api/archive/filters接口，并传入你感兴趣的moduleId，你就能得到一份详细的筛选条件列表。例如，请求{域名地址}/api/archive/filters?moduleId=1，返回的数据结构会告诉你，当前模型下有哪些筛选器（如“城市”、“学历”），以及它们对应的字段调用名称（field_name）和所有可选的参数选项（items.label）。
这份数据至关重要，它就像一份筛选功能的“地图”。其中，field_name是每个筛选条件在后端系统中的唯一标识，也是我们后续构建查询参数时会用到的键名。而items数组中的label字段，则是前端展示给用户选择的具体选项，比如“北京”、“上海”或是“硕士”、“本科”等。
应用筛选条件获取文档列表 (/api/archive/list)
现在我们已经知道了可以按哪些维度进行筛选，接下来就是如何将用户的选择转化为实际的查询请求，并提交给/api/archive/list接口。这个接口负责根据你提供的参数，返回符合条件的文档列表。
/api/archive/list接口不仅支持常规的moduleId、categoryId、page、limit、q（搜索关键词）等参数，更强大的是它允许你添加自定义筛选参数。这些自定义参数的键名，正是我们从/api/archive/filters接口获取到的field_name。
举个例子，如果/api/archive/filters告诉我们有一个field_name为city的筛选器，并且它有“北京”、“上海”等选项。那么，当用户选择了“北京”时，我们就可以向/api/archive/list接口发送一个查询参数，形如city=北京。完整的API调用看起来会像这样：{域名地址}/api/archive/list?moduleId=1&type=page&city=北京。
如果用户同时选择了多个筛选条件，比如既要查找“北京”的文档，又要筛选“本科”学历，那么我们只需将这些筛选参数通过URL的Query String形式叠加即可：{域名地址}/api/archive/list?moduleId=1&type=page&city=北京&certificate=本科。请注意，为了启用筛选功能并获取总数，type参数通常应设置为page。
此外，你还可以结合其他参数来进一步优化结果，例如使用order参数指定排序方式（如order=views desc按浏览量降序），或者使用q参数进行关键词搜索，这些都可以与自定义筛选参数无缝配合。
实际操作步骤与前端实现思路
为了更清晰地理解整个流程，我们来梳理一下在实际开发中如何利用这两个接口构建一个动态筛选内容的功能：
- 步骤一：明确目标模型 在你的页面或组件加载时，首先确定你希望筛选哪个文档模型下的内容，获取其