通过自定义 filterOptions 函数，返回原始 options 数组即可完全禁用 MUI Autocomplete 的客户端过滤逻辑，使其始终展示所有传入的选项（适用于服务端已预过滤的场景）。
通过自定义 filteroptions 函数，返回原始 options 数组即可完全禁用 mui autocomplete 的客户端过滤逻辑，使其始终展示所有传入的选项（适用于服务端已预过滤的场景）。
在使用 MUI 的 <autocomplete></autocomplete> 组件时，其默认行为会对 options 进行客户端模糊匹配（基于输入值），这与服务端已完成过滤（如 Elasticsearch 或 Algolia 返回的精准结果）的场景存在冗余甚至冲突。若你已通过 searchFunctions.convertHitsToOptions(searchQuery.data) 将服务端返回的“命中结果”转换为选项列表，则应彻底关闭 Autocomplete 的内置过滤。
核心解决方案：
只需将 filterOptions 设为恒等函数（identity function），即直接返回传入的 options 数组：
<autocomplete getoptionlabel="{(option)"> option.projectName ?? String(option)}
options={searchFunctions.convertHitsToOptions(searchQuery.data)}
filterOptions={(options) => options} // ✅ 关键：禁用所有过滤
renderInput={(params) => (
<textfield label="项目名称" variant="outlined"></textfield>
)}
/></autocomplete>
? 注意：
filterOptions接收两个参数 ——(options, state)，其中state.inputValue是当前输入值。但在此场景下无需使用它；直接返回options即可跳过所有匹配逻辑。
补充说明与最佳实践：
- 若需保留清空输入后仍显示全部选项（而非仅在首次展开时），请确保
options始终为最新、非空数组（例如配合useEffect或React.memo避免 stale props）； - 不建议设置
disableListWrap或openOnFocus等属性来“模拟”常开效果——它们无法解决过滤问题，且影响可访问性； - 如需支持键盘导航（↑↓）和回车选中，该方案完全兼容，因
options未被截断，列表结构完整； - 若后续需添加轻量级高亮或排序（如按相关性字段），可在
filterOptions中扩展逻辑，但仍绕过inputValue匹配。
总之，filterOptions={(options) => options} 是最简洁、语义清晰且符合 MUI 设计意图的禁用过滤方式，既保证功能正确性，又保持代码可维护性。
