搜索怎么做？项目成员落地方案：列表视图从0到1

《搜索怎么做？项目成员落地方案：列表视图从0到1》的关键，不是先画一个输入框，而是先回答四个问题：用户要找什么记录、可以搜哪些字段、能看到哪些数据、搜索结果如何与筛选和分页配合。前面任何一项没定清楚，最后都可能出现“搜得到但不该看到”“看得到但搜不到”或“搜索条件一清空，其他筛选也跟着丢失”的返工。

我会把列表搜索看成一条可验收的业务链路，而不是一个孤立控件：用户提出查找任务，团队明确对象和范围，设计搜索与结果状态，研发落实查询规则，测试验证正确性和权限，最后通过真实使用反馈决定要不要增加高级能力。本文以一个项目管理后台的项目列表为贯穿示例，示例中的数据均为情景模拟，不代表行业统计或真实客户项目。

一、先讲结论：列表搜索先定规则，再做输入框

1. 把搜索需求写成一句可验证的话

我通常先要求需求方把“列表不好找”改写成一句完整描述：谁在什么列表里，要找哪类记录，凭哪些信息定位，结果受什么范围限制，找到后要完成什么动作。比如：“项目成员在自己有权访问的项目列表中，输入项目名称或项目编号，定位项目并进入详情页。”

这句话看起来简单，却已经划定了搜索对象、搜索字段、权限边界和用户目标。相反，“增加一个搜索框”没有说明任何业务规则，产品、设计、前后端和测试很容易各自补全假设，直到联调时才发现彼此理解不同。

2. 先交付最小闭环，不要一开始就做成搜索引擎

列表搜索的第一版通常只需要完成一件事：用户输入明确关键词后，列表返回符合已确认规则且当前用户可见的记录，并清楚展示结果状态。拼音联想、搜索历史、热词、复杂权重排序和跨模块检索都不是默认必需项。

我的判断顺序是：正确性和权限优先，其次是交互可理解，再评估速度与便利性。如果搜索能在毫秒级返回，却把无权查看的记录暴露在结果里，这不是体验优化，而是安全缺陷；如果结果正确但用户不知道当前条件是什么，也会产生“搜索不准”的错觉。

3. 用一张范围表压住返工

在进入原型和接口设计前，至少把对象、字段、范围、匹配、组合、状态和验收写到同一张表里。遇到暂时无法决定的内容，标记负责人和决策时间，不要把“默认大家都懂”当作需求结论。

二、背景和真实场景：用户说“找不到”，不一定是搜索框不够用

1. 先区分“定位困难”和“数据不存在”

项目成员反馈“项目列表搜不到”，可能是记录确实不存在，也可能是名称记错、关键词字段不在搜索范围、当前筛选条件把记录排除了，或用户没有访问权限。把这些情况一律归因于“搜索体验差”，往往会导致团队不断增加搜索字段，却没有解决真正的问题。

我会先复现用户的查找路径：用户从哪个页面进入，列表当前是否有筛选条件，记得项目名称还是编号，输入了什么，系统显示了什么，用户预期下一步做什么。必要时将问题拆成三类：找不到记录、结果太多、找到了却无法确认是不是目标记录。

2. 列表的规模和使用频率决定搜索形态

只有十几条记录、且用户很少查找的列表，搜索框未必比现有筛选器更有价值；记录持续增长、名称相似、用户反复定位特定对象时，关键词搜索才可能明显减少操作。这里不建议套用一个统一的“超过多少条就必须搜索”的行业阈值，团队应结合记录规模、查找频率和用户任务验证。

例如，同一后台里“项目列表”和“项目成员列表”的查找模式可能完全不同。项目列表常按名称、编号、状态和负责人定位；成员列表可能更依赖姓名、邮箱、团队和角色。把一个列表的字段方案原样复制到另一个列表，常常只是增加了看上去相似、实际上不匹配的功能。

3. 建议记录查找过程，而不只收集功能愿望

需求访谈中，用户很容易说“最好支持模糊搜索、拼音搜索和历史记录”。这些是方案建议，不是问题本身。我会追问最近一次找不到记录的具体过程：搜索了什么、耗时多久、重复尝试几次、最后如何找到，或者是否通过其他人协助完成。

对团队而言，最有用的材料不是“用户想要更多搜索功能”，而是一组能重现的问题样本。比如：目标项目编号为“PRJ-2048”，用户只记得“2048”；项目名称中包含相似词；状态筛选仍停留在“进行中”，而目标记录已归档。每个样本都能指向不同的产品或数据原因。

三、常见误区：看上去在做搜索，实际在制造新问题

1. 误区一：字段加得越多，搜索就越好用

字段越多，用户不一定越容易找到目标。搜索名称、描述、备注、成员、标签、附件内容后，结果可能变多、难以解释，也可能让用户误以为每个字段都支持同一种匹配方式。对于敏感字段，未经评估地扩大检索范围还会带来信息暴露风险。

我的做法是先列出候选字段，再为每个字段说明用户为什么会用它、字段是否稳定、是否可见、匹配后是否能帮助确认目标。无法说明用途的字段，先不进入首版范围。上线后若无结果查询集中出现在某类输入，再评估是否值得扩展。

2. 误区二：把搜索和筛选混成一个大输入框

关键词搜索适合表达不完整、自由度较高的信息，例如“记得名称里有交付”；筛选器适合表达明确的结构化条件，例如“状态等于进行中”“负责人等于李明”。两者可以同时存在，但不应让用户猜测系统如何解释每个条件。

如果用户既要搜项目名称，又要限制负责人和状态，界面应保留三者当前状态，并说明它们是共同缩小结果范围，而不是某个条件悄悄覆盖另一个条件。清除关键词时是否保留状态筛选，应在交互和验收中明确，而不是由开发实现习惯决定。

3. 误区三：默认实时搜索，忽略请求成本和输入体验

实时搜索对短列表、轻查询、快速反馈的场景可能合适；对高频请求、网络条件不稳定或查询成本较高的列表，逐字符请求可能造成重复调用、结果闪动和旧请求覆盖新请求。也有用户希望输入完整后按回车确认，此时实时触发并不一定更快。

因此，实时还是提交触发，需要结合响应时间、列表更新频率、用户输入习惯和请求成本选择。无论选择哪一种，都要处理连续输入期间的状态：旧结果是否先保留、请求失败是否清除输入、快速输入时如何避免过期结果覆盖最新查询。

4. 误区四：只验“搜得到”，不验“搜不到时怎么办”

空结果不是边缘情况，它是搜索体验的一部分。系统至少需要让用户知道当前关键词和筛选条件仍然生效，并给出可执行的下一步，例如检查拼写、清除条件或确认记录是否在可见范围内。

“无结果”文案也不应泄露权限细节。对于受权限限制的记录，不能为了让用户理解“为什么没搜到”，就直接提示存在某条不可见记录。权限策略需要由业务和安全要求决定，界面提示只应提供允许公开的信息。

5. 误区五：把复杂搜索能力当作首版必选项

拼音匹配、同义词扩展、搜索历史、联想词和权重排序都可能有价值，但每一种能力都增加了需求、实现、测试和后续维护成本。数据量小、字段清晰、用户主要按编号定位的列表，未必需要引入复杂的检索机制。

首版的目标不是功能数量多，而是规则简单、行为可预测、结果可信。当基础方案的正确性和使用情况还没有被验证时，增加高级能力往往只会扩大问题面。

四、专业判断逻辑：用六个问题决定搜索方案

1. 搜索对象是什么，记录的唯一身份是什么

先确认用户要找的是哪种实体，以及什么信息最能稳定地指向它。项目编号通常比自由文本描述更明确；项目名称更符合用户记忆，但可能重名或改名。若系统存在唯一编号，应评估它是否应该成为首版重点字段，而不是只围绕名称设计。

还要区分列表当前展示的记录与搜索后台可查询的记录。用户看到的是当前页数据，还是整个有权访问的数据集合？如果只对当前页做前端过滤，用户可能误以为其他页或其他状态下的记录不存在。这个边界必须在需求说明中写清楚。

2. 搜索字段是否稳定、可理解、可被用户记住

字段的选择不应只看数据库里有没有。一个字段即使可查，用户也未必知道它的格式；一个字段看起来常用，也可能经常为空或被修改。建议把字段分成“首版必需”“待观察”和“不纳入”三类，并记录每项决策依据。

3. 哪些条件是交集，哪些条件是替代

当关键词同时匹配名称和编号时，通常需要先明确两种字段的关系：任一字段命中即可返回，还是某些字段有优先级。关键词与筛选器也要明确是交集还是覆盖。多数列表场景中，关键词结果再叠加状态、负责人筛选，意味着结果同时满足这些条件；但最终仍应由业务规则确认。

对产品和测试来说，一句“支持组合查询”远远不够。应进一步写出组合规则，例如：“关键词匹配项目名称或编号；负责人、状态筛选均与关键词结果取交集；清除关键词后保留负责人和状态。”这句话可以直接转化成验收用例。

4. 搜索结果要能让用户判断“这是我要找的吗”

结果数量多时，只返回名称可能不够。可以考虑展示项目编号、负责人或状态等辅助信息，但前提是这些信息对当前用户可见，且不会让列表过度拥挤。高亮命中词也不是必需项；如果实现成本较高，首版优先保证结果准确与状态清晰。

排序同样需要业务解释。若列表本身默认按更新时间排序，搜索后是否延续该排序？编号精确匹配是否置顶？名称部分匹配是否和编号匹配同权？没有明确价值时，不要引入用户难以理解的隐式排序。

5. 查询范围是否满足权限和数据生命周期规则

搜索不应绕过列表原有权限。后端必须在查询过程中落实访问控制，不能只在前端隐藏结果。还要确认草稿、归档、已删除、历史版本等记录是否参与搜索，以及用户权限变更后，缓存或已展示结果如何更新。

这项工作常被误认为纯技术细节，但实际上会影响产品定义和测试矩阵。项目负责人、产品和研发需要共同确认：哪些角色能搜哪些记录，权限被撤销后是否立即不可见，是否允许从搜索结果进入详情页。

6. 方案复杂度是否与查找收益匹配

简单列表可以采用基础文本查询和现有筛选器；数据量、查询复杂度或跨字段需求上升后，再评估索引、异步查询或更复杂的检索机制。架构选择应由数据规模、响应要求、权限模型和运维能力共同决定，不能从“要做搜索”直接推导出必须建设完整搜索系统。

下面的决策图采用情景模拟数据，目的是帮助团队比较工作量与收益，不是承诺任何产品可以达到对应效果。实际项目应使用团队估算和上线数据替换。

五、具体案例：从一个项目列表需求走到可验收方案

1. 场景说明：成员要在项目列表中定位项目

以下是一个明确标注的示例场景：某项目管理后台有项目列表，成员可以按项目名称、项目编号、负责人和状态浏览记录。成员反馈“项目多了以后不好找”，团队暂时没有真实量化数据，因此先通过访谈和问题样本确认查找任务，再制定可验证的首版范围。

示例中的目标不是“做一个功能最全的搜索”，而是降低用户在列表里反复翻页和尝试筛选的成本。为避免凭空宣称收益，团队可以在上线前记录一批典型任务的完成时间和成功情况，再用相同类型的任务进行对照。

2. 第一步：把需求拆成用户任务和边界

团队先把用户任务写成：“输入项目名称或编号中的一部分，在当前用户有权访问的项目范围内找到目标项目。”随后补充：归档项目是否默认参与搜索、负责人和状态筛选是否保留、名称匹配是前缀还是包含关键词、结果按什么规则排序。

这些问题不必都由产品经理单方面决定。归档规则由业务确认，匹配方式由产品与研发评估，权限范围需要结合现有授权模型，结果排序则由用户任务和默认列表规则共同决定。每项未定内容都应记录责任人，防止它们在开发过程中被默认为实现细节。

3. 第二步：为首版划定“做”和“不做”

在这个示例中，团队可以把首版范围暂定为：名称和编号支持关键词匹配；负责人、状态作为独立筛选条件；搜索结果限定在用户可见数据内；提供清空关键词的操作；覆盖有结果、无结果、加载和请求失败状态。

首版暂不承诺拼音匹配、同义词、搜索历史和跨模块全文检索。这不是否定它们的价值，而是把决策留到有证据之后。如果用户主要输入准确编号，拼音能力可能没有明显收益；如果用户反复寻找不同模块里的对象，跨模块检索才可能成为更合理的独立需求。

4. 第三步：约定交互状态和条件生命周期

用户输入关键词后，系统何时发起查询、如何显示加载状态、如何清除关键词、是否保留其他筛选，都要形成一致规则。对于提交触发的方式，要说明按回车还是点击按钮；对于实时触发，要说明请求节流、旧请求处理和输入未完成时的展示策略。

还需要把条件生命周期画清楚：翻页是否保留搜索条件，切换列表视图是否保留，离开页面再回来是否恢复，点击重置会清除哪些条件。最常见的体验断点不是搜索算法，而是用户刚找到一条记录，返回列表后发现条件丢失，必须重新输入。

5. 第四步：把方案写成前后端和测试都能执行的约定

产品需求不必替研发规定具体技术实现，但要清楚说明输入、输出和约束。例如：查询对象为项目；允许搜索的字段是名称和编号；结果必须遵守当前用户的数据权限；与负责人和状态筛选共同生效；空关键词的行为与清除操作一致。后端据此确认接口字段与分页方式，前端确认条件状态和交互反馈，测试据此编写用例。

如果接口还没有定型，可以先建立字段约定表，而不是在不同文档里各写一套说法。尤其要避免同一个“搜索词”在前端叫关键词、接口叫名称、测试用例却按编号理解，导致联调时才发现“支持搜索”的含义并不相同。

6. 第五步：用任务完成过程衡量，而不只统计点击

评估首版效果时，我更关注用户是否能正确找到目标记录、完成任务用了多久、是否需要重复修改关键词，以及无结果后能否自行调整。搜索框点击量只能说明入口被使用，不能单独证明搜索变得更有效。

建议记录观察口径和样本来源。例如，挑选同一组代表性查找任务，在功能上线前后各邀请相近角色完成，记录耗时、成功率和重复尝试次数。样本数量不足时，只能把结果作为方向性观察，不能包装成普遍结论。

六、项目成员怎么协作：按交付物分工，而不是只列岗位名称

1. 产品：把业务规则变成可决策、可验收的需求

产品负责明确用户任务、搜索对象、字段范围、权限边界、匹配规则和条件组合方式。产品还应整理暂不支持项，避免团队在开发中不断接收没有优先级的功能愿望。一个合格的需求文档，不是写得越长越好，而是关键行为没有模糊地带。

推荐交付物包括：需求范围表、关键场景说明、条件组合规则、状态清单、验收标准和待决策问题。对于尚无依据的高级能力，可以注明验证方式和进入下一阶段的条件，而不是直接承诺上线。

2. 设计：覆盖完整状态和条件可见性

设计不能只交付默认态的搜索框。至少要处理未输入、输入中、加载中、有结果、无结果、请求失败、条件已应用、条件已清除等状态，并确保用户看得出当前结果受哪些条件影响。

如果列表同时存在关键词、负责人、状态和时间范围等条件，设计要说明每个条件的展示与清除方式。单独清除关键词和重置全部条件应是不同动作，视觉层级也要避免用户误点后丢失其他筛选。

3. 前端：管理输入状态、请求状态和列表状态

前端要与产品和后端确认查询触发方式、分页重置规则、排序保留规则以及请求失败时如何恢复。搜索条件改变后是否回到第一页，通常需要明确；否则用户在较后页输入新关键词，可能看到空页并误以为没有匹配结果。

前端还要处理快速连续输入、重复提交和响应顺序问题。具体实现方式由技术方案决定，但验收应关注最终展示的结果对应最新有效条件，而不是被较早发起的请求覆盖。

4. 后端：保证查询规则、权限与分页一致

后端要确认字段匹配方式、权限过滤位置、分页和排序规则，以及数据量增长时的查询成本。权限限制应在服务端生效；分页总数、当前页结果和筛选条件需要保持一致，不能只在页面上过滤一部分返回数据。

如果搜索跨多个字段，还应确认字段为空、字段值变化和特殊字符输入时的行为。是否需要索引或其他优化，应根据实际数据规模和响应要求评估，不应让“列表搜索”自动变成大规模架构改造。

5. 测试与项目负责人：关注跨角色约定和风险闭环

测试负责把需求规则转成正常、异常、边界和权限用例；项目负责人则关注依赖是否齐全、决策是否有人负责、范围是否在联调前冻结。两者都不应只在功能开发完毕后才进入，而应在规则讨论阶段提前参与。

跨职能协作最容易漏掉的，不是某个人“没做好”，而是不同角色拿到的规则版本不一致。建议维护一份唯一的规则来源，接口说明、设计稿和测试用例都引用同一套字段名称和条件语义。

七、测试与验收：搜索正确，不等于用户能顺利完成任务

1. 正常路径：验证规则与用户预期一致

测试要覆盖完整编号、部分编号、完整名称和名称片段等代表性输入，并确认结果是否符合已约定的匹配方式。若搜索名称或编号的任一字段命中即可返回，测试就要验证两种字段各自命中，以及两者都命中时结果如何呈现。

还要检查输入关键词后列表是否回到合理页码，分页总数是否更新，排序是否符合约定。只看第一屏是否出现某条记录，无法覆盖分页和排序带来的错判。

2. 组合路径：关键词与筛选器一起工作

至少验证关键词与负责人、状态筛选同时生效，以及清除关键词后其他条件是否按约定保留。再检查重置全部条件是否真的清除所有状态，刷新页面或返回列表后是否出现符合设计的恢复行为。

如果用户可以切换项目空间、组织或视图，还应验证搜索条件是否意外跨范围保留。不同列表复用同一个搜索组件时，也要确认各列表字段规则没有互相污染。

3. 边界路径：输入不完整或不规范时仍有明确反馈

边界测试可以包含空白输入、前后空格、连续空格、特殊字符、超长内容、大小写差异和不完整编号。是否忽略空格或区分大小写应根据业务规则确定，测试的目标是保证系统行为稳定且一致，而不是要求所有场景都采取同一种处理方式。

测试也要覆盖请求超时、服务异常和快速连续输入。失败时是否保留用户已输入的关键词、能否重试、是否提示当前结果可能过期，都需要有明确处理。不要让错误状态伪装成正常的“无搜索结果”。

4. 权限路径：确认不可见数据不会从搜索结果中泄露

准备至少两种权限角色，验证每个角色只能看到授权范围内的项目。即使用户知道某条记录的准确名称或编号，也不能通过搜索绕过访问控制；搜索结果、数量、摘要字段和后续详情跳转都应符合权限规则。

权限用例还要考虑权限变更后的行为。用户访问页面期间被撤销权限，已缓存的结果如何更新，重新查询时是否立即生效，应按照系统的安全和一致性要求确认。

5. 用验收表让“通过”有共同定义

响应时间和准确率不应凭空套用一个“行业标准数字”。团队应先确认数据量、并发条件、网络环境和页面更新方式，再给出项目自己的性能目标，并保留测试口径。没有统计条件的单次测量，不适合写成上线效果承诺。

八、不同情况下的行动建议与能力取舍

1. 列表较小、查询频率低：先不要为了完整而新增复杂入口

如果用户能通过现有列排序或筛选快速定位记录，且没有持续的找不到反馈，可以先观察而非立即增加搜索。确认用户是否真的需要自由关键词，再决定是否增加入口。功能越多并不必然意味着列表越好用，额外入口也会增加认知负担。

2. 记录持续增长、用户常按名称或编号查找：先做基础关键词能力

如果用户反复定位项目，名称或编号是稳定信息，基础关键词加现有筛选器通常是更合适的起点。首版重点是字段规则、数据权限、清空行为、分页重置和空结果提示，先让基本链路可信。

3. 用户任务以确定条件为主：优先完善筛选器

如果用户总是明确知道负责人、状态、时间范围等条件，问题可能不是缺少关键词搜索，而是筛选器难用、字段命名不清楚或条件组合效率低。此时把筛选器做得可见、可组合、可清除，可能比增加自由文本搜索更直接。

4. 数据规模大或查询性能不稳定：先做技术评估，不先承诺界面能力

当查询跨多字段、数据量增长快、列表响应不稳定或权限过滤成本较高时，应让研发评估数据访问路径、索引策略、分页方式和缓存影响。产品可以定义用户任务和体验目标，但不应在评估前承诺某种底层技术必然可行。

5. 用户反复查找相似目标：有证据后再加联想或历史能力

如果用户经常忘记准确名称、重复搜索同一批记录，联想或搜索历史可能减少输入成本。但要先确认记录是否有稳定标识、历史是否涉及敏感信息、用户是否共享设备，以及历史记录的保存和删除规则。体验便利不能凌驾于权限和隐私要求之上。

6. 搜索结果过多：先改善识别与筛选，不急着堆排序规则

结果太多时，可以先检查字段是否过宽、当前筛选器是否易用、结果卡片是否缺少编号或状态等识别信息。只有当用户确实需要系统判断“哪个结果更相关”，并且团队能解释排序依据时，才考虑增加相关性排序。

九、上线后的复盘：把“感觉不好用”变成可处理的问题

1. 记录有解释力的行为，而不是只看搜索量

建议关注查询次数、无结果比例、重复修改关键词的比例、从输入到进入目标记录的完成时间，以及搜索后立即清空或离开的情况。这些信号要结合上下文解读：无结果可能说明字段范围不足，也可能是用户输入错误、记录不存在或权限受限，不能看到一个指标升高就直接扩大搜索范围。

日志应遵循组织的数据治理要求。关键词可能包含项目名称、客户信息或其他敏感内容，是否保存原始查询、保存多久、谁可以访问，都需要先进行合规和安全评估。很多场景可以优先使用聚合统计或脱敏样本，而不是长期保留可识别的完整输入。

2. 把失败样本分类，决定下一步改什么

每轮复盘都可以把问题归入字段缺失、匹配方式不合适、筛选状态不清、结果识别信息不足、权限规则不明、数据质量问题和性能问题等类别。分类之后再确定负责人和验证动作，避免产品只收到“搜索不准”的笼统反馈。

如果用户反复输入编号片段却无结果，优先检查编号字段是否在查询范围、格式是否一致；如果用户搜到很多相似名称，优先补充识别信息或提供结构化筛选；如果用户常因归档状态遗漏记录，先确认业务是否允许搜索归档项目，而不是直接修改排序。

3. 设立迭代门槛，避免高级功能自然膨胀

可以为每项增强能力设一个明确的进入条件。例如，搜索历史需要有重复查找样本和隐私评估；联想需要有足够稳定的候选数据和可解释的排序规则；复杂匹配需要证明基础匹配无法满足主要任务。门槛不必复杂，但要防止“竞品有、用户可能想要”直接变成开发承诺。

同样重要的是识别不该由搜索解决的问题。项目名称规范混乱、负责人字段缺失、归档规则不一致，可能需要治理数据或优化业务流程。搜索可以帮助定位信息，却不能替代数据质量管理。

十、可直接带进评审会的落地清单

1. 需求确认清单

• 用户在什么列表、什么任务中需要搜索？
• 搜索对象是什么，记录的稳定标识是什么？
• 首版支持哪些字段，哪些字段明确不支持？
• 搜索范围是当前视图、当前项目，还是当前用户有权访问的全部记录？
• 归档、删除、草稿和历史记录是否参与搜索？
• 关键词匹配规则是什么，关键词与筛选器如何组合？
• 排序、分页、清空和重置行为是否明确？
• 无结果、加载中、请求失败和权限限制如何反馈？
• 上线效果用什么任务、样本和口径验证？

2. 评审会上必须有人回答的问题

我建议至少让产品、设计、前端、后端和测试各自回答一个问题：产品说明业务范围，设计说明状态与条件可见性，前端说明交互状态和请求顺序，后端说明权限与查询边界，测试说明如何证明结果正确。项目负责人则确认未决事项有责任人、有截止时间，并且不会在联调阶段突然改变范围。

如果有人只能回答“按常规做”，就说明规则还没有真正落地。搜索功能看似简单，最容易被省略的恰好是团队对“常规”的理解并不相同。把这类分歧留在需求评审解决，通常比在上线前修复结果错误更省成本。

3. 最后的判断：搜索是查找任务的入口，不是目的

一套好的列表搜索，不以输入框是否醒目、功能是否丰富来衡量，而以用户能否在正确权限范围内，用符合直觉的信息找到目标记录，并知道下一步该做什么来衡量。它的质量来自字段选择、数据规则、交互状态、权限控制和验收方法的一致，而不是某个单独的算法名词。

下一步可以先挑一张真实业务列表，收集十个“找不到或找得慢”的具体样本，按字段、筛选、权限、数据状态和性能分类；再用一页范围表定下首版规则，安排一次覆盖组合条件与权限边界的验收。先把基础链路做对，再用真实使用证据决定要不要做联想、历史或复杂匹配，这比一次性把搜索功能做满更稳妥，也更容易交付。