中小商家做电商 CRM 改造，最容易走偏的不是权限开得太宽，而是把“合规”理解成给每个岗位多加几道限制：客服看不到必要的售后记录，运营为处理活动临时借用管理员账号，最后系统里权限表面收紧了，实际操作却转移到了共享账号、表格和聊天工具里。改造的重点不是把门锁得更复杂，而是让每个人在完成业务任务时，只能接触到完成任务所需的数据和操作，并且在岗位变化、人员离职、批量导出等节点留下可检查的记录。
我判断一套电商 CRM 权限是否设计到位，通常不会先看角色数量，而会先拆成三个问题：谁在什么业务场景下进入系统，需要看到哪些范围的数据，又需要执行哪些操作。三者混在一起，最常见的结果就是“客服”被配置成一个大角色，既能查客户、改客户，又能批量导出；或者运营需要看全店数据，系统就干脆给了管理员权限。
这三个问题应分别形成清单。人员清单解决账号归属和身份问题；数据清单解决门店、店铺、渠道、客户归属等可见范围；操作清单则区分查看、编辑、删除、导出、授权等动作。同一个人可以需要看较多数据，却不需要修改或导出；也可能只看少量数据，但需要执行特定的售后操作。
因此，我更倾向于把权限模型理解为“岗位任务 × 数据范围 × 操作类型”的组合，而不是“岗位名称 = 一组固定权限”。岗位名称只能作为起点，不能代替对实际工作的核对。
日常查看订单与批量导出客户名单，不应被当成同一等级的权限。前者可能是客服处理单笔咨询的必要动作，后者则可能一次性把大量数据带离 CRM。删除记录、修改账号权限、变更客户归属、批量修改状态等操作，也可能影响更大的业务范围。
我建议至少将权限分成三层：日常查询与处理、影响业务状态的修改、高影响或难以逆转的操作。第三层不一定都要增加审批，但至少要明确授权对象、触发条件、有效期限和记录方式。是否审批，要看操作的影响面、恢复难度和业务时效，不宜简单套用“一律审批”。
小团队不需要一开始就设计几十种角色。角色过多会增加配置、培训和复核成本，也容易出现“没人知道某个角色为何存在”的情况。第一阶段应优先处理共享账号、离职未停用账号、全量导出权限、管理员权限泛化，以及第三方工具访问范围不清等明确问题。
适合中小商家的顺序通常是：先能分辨账号属于谁，再能说明账号为什么需要某项权限，接着控制高影响操作，最后根据真实业务差异细分数据范围。权限体系的成熟，不体现在角色数量上，而体现在每项授权都能解释、能回收、能复核。
设想一家经营多个线上店铺的商家：活动期间，运营需要核对某批订单的客户反馈，管理员临时开放了客户数据导出。活动结束后，运营回到常规工作，权限却没有同步收回。几个月后，团队已经记不清这个权限最初因为什么开通，也没人确定哪些人仍然保留着它。
这类场景并不需要假设有人恶意操作。权限遗留往往来自工作交接不完整、账号没有归属人、临时任务没有到期日，或系统无法快速区分“看数据”和“导出数据”。因此，权限治理首先是一项运营管理工作，其次才是系统配置工作。
客服轮班、外包团队短期支援、门店临时协作，都可能促使团队共用账号。共享账号看似减少了开通流程，却让操作记录无法稳定对应到具体人员。出了误改、误删或异常导出，管理者只能看到“某个账号做过”，很难进一步还原由谁、在什么任务下操作。
如果系统暂时不支持完善的个人账号或角色管理，也不建议把共享账号当成永久方案。可以先建立账号责任人、使用期限、密码交接规则和关键操作登记，同时制定系统升级计划。临时控制不能替代长期身份管理，但比完全不记录要好。
权限检查只看 CRM 菜单，容易漏掉数据的其他出口：批量导出文件、浏览器下载、第三方客服工具、营销插件、接口调用、外包服务账号，以及员工将数据复制到本地表格后的二次流转。改造时不必假设每个出口都存在风险，而要先确认数据实际从哪里进入、在哪里被使用、如何离开系统。
这也是为什么“CRM 里已经按角色限制了”不能自动等同于“数据访问边界已经清楚”。系统权限只覆盖系统能够控制的部分；接口、外部服务和人工导出，还需要通过合同约定、账号管理、数据范围和业务流程一起治理。
涉及客户姓名、联系方式、地址、订单关联信息等内容时，企业应结合实际业务用途和适用规则进行审查。个人信息保护相关要求强调处理目的、处理方式和信息种类等应有相应依据，并对受托处理、采取安全措施等事项作出要求。实际适用到某个 CRM 流程时，还要核对业务关系、处理目的、数据类型和具体操作，不能只凭“用了 CRM”就推导出统一结论。
如果文章或企业制度要引用法律条文，应核验现行有效文本和适用范围。本文提供的是权限治理与流程设计建议，不构成针对具体企业的法律意见，也不意味着配置某个角色就能自动满足全部合规义务。
角色增加只能说明配置颗粒度变细，不代表权限设计更准确。如果角色名称很多，却没有维护责任人、适用岗位和调整条件，系统很快就会出现多个权限相近的角色。实施人员为了让业务继续推进，可能直接复制旧角色再略作修改，最后无人敢删、无人能解释。
我更建议先建立少量基础角色，再用数据范围和限时授权处理确有必要的差异。例如普通客服、售后专员、运营分析人员可以作为基础岗位模型；跨店铺支援、专项复盘或短期外包，则作为有期限的例外授权管理。只有当例外反复出现、职责稳定且边界清楚时，才值得沉淀为长期角色。
同叫“客服”的人，工作内容可能完全不同。有人处理售前咨询，有人负责退款和投诉，有人需要跨店铺排查问题，还有人只做夜班基础接待。若一律按岗位名称授权，容易出现两种情况：为照顾少数复杂任务，把整个岗位权限开得过大；或为了限制风险，让大多数员工频繁申请临时权限。
更可靠的做法是记录岗位的高频任务与例外任务。高频任务用基础权限满足；低频但必要的任务通过申请、限时授权或主管代办机制解决。判断标准不是“这个人属于哪个部门”，而是“这个动作对完成任务是否必要，权限范围是否超过任务所需”。
关闭导出按钮有价值，但它只控制一种路径。若员工仍能逐条复制、通过接口查询、在另一个系统下载，或者让管理员代为导出，风险并没有因此消失。反过来，完全禁止导出也可能阻断财务核对、售后分析等合理工作，促使团队转向未纳入管理的替代办法。
因此，导出治理应先问四件事：什么任务需要导出、导出字段是否能减少、导出范围是否能限定、文件在任务结束后如何存放或清理。对确有必要的导出，可以考虑角色限制、审批、用途说明、文件水印或操作日志等措施；具体能否配置取决于系统能力。
管理员通常能做的事情远多于一线岗位的日常需要。将其当成“解决权限报错”的万能办法，短期内减少了工单，长期却让高影响操作散落到更多账号上。更好的处理方式是先识别报错对应的具体任务，再给出最小范围的权限，或设计由有权限的负责人完成特定动作。
管理员账号也需要明确使用者、授权原因和复核周期。对小团队而言，不一定马上建设复杂的双人审批，但至少要避免管理员账号长期多人共用，并把账号权限变更、批量操作等关键活动纳入记录与检查。
权限不是一次性配置。员工入职、调岗、离职，店铺扩张、组织调整、业务外包，都会改变原来的授权依据。如果流程里没有这些触发事件，系统即使上线时配置正确，也会随着时间变得不准确。
验收时除了测试“应该能做什么”，还要测试“岗位变化后怎样变更”“临时权限怎样到期”“人员离职后谁通知系统管理员”“误授权怎样发现和纠正”。权限治理的验收对象不只是配置结果，更是配置生命周期。
一个权限申请如果只写“工作需要”，很难判断是否合理。应尽量写成可验证的任务描述，例如“售后人员需要查看本人负责订单的退款进度，以回应客户询问”，而不是“售后需要看订单”。任务越具体，就越容易拆出必要字段、数据范围和操作类型。
我通常会追问：没有这项权限，任务会如何受阻？是否能通过缩小数据范围、由指定岗位代办或使用汇总结果完成？如果权限带来的收益有限，却扩大了大量数据的可见范围，就应优先寻找替代方案。反过来，若一线任务有明确时限，过度审批造成持续延误，也要把业务损失纳入判断。
不是所有权限都需要同样强的控制。查询单笔订单、修改客户备注、批量导出、删除记录、调整全局权限，影响范围和恢复难度差异明显。可以采用内部的定性分级：低风险操作以角色和数据范围控制为主；中风险操作增加记录和定期复核；高风险操作再考虑审批、限时授权或双人复核。
这不是统一的法定分级表，也不应把简单评分包装成合规结论。它的作用是帮助资源有限的团队先处理影响大的事项。若企业已有风险分类制度，应沿用并对齐，而非另造一套口径。
身份层回答账号属于谁、是否为个人账号、是否仍在职；数据范围层回答可以访问哪些店铺、渠道、客户或订单；动作层回答可以查看、编辑、导出、删除还是配置权限。三个层次分开后，团队才能解释为什么某人能处理本人负责的售后单，却不能查看全店客户名单。
配置时可以先用岗位角色解决常见动作，再用门店、店铺或客户归属等规则限定范围。若 CRM 不支持足够细的控制，不要假装界面上有一个开关就解决了问题，应记录系统限制，并通过流程、人工复核或系统替换评估补足。
临时授权至少应有申请人、审批人或责任人、任务原因、权限范围、起止时间和回收确认。授权有效期可以按任务周期设定，而不是给出一个过长的默认期限。任务结束后，若确实需要长期保留，应重新说明业务依据，而不是让临时授权自动变成永久授权。
遇到紧急故障或高峰活动，团队可以设计紧急授权流程，但事后要补充记录和复核。紧急机制的重点不是追求“任何时候都不出例外”，而是让例外可识别、可说明、可收回。
日志若只是长期保存、从不查看，实际治理价值有限。小商家可以先关注少数高信号事件：批量导出、管理员权限变更、离职账号仍有活动、临时授权超过期限、高影响操作集中发生等。发现异常后，要有负责人判断它是合理业务行为、配置问题还是需要进一步核查。
复核频率可按风险与团队能力制定，不必为了形式要求所有岗位每天检查。关键是明确谁负责、看哪些事件、发现问题后如何处理，以及处理结果是否闭环。日志能力不足时，应将其列入系统能力差距，而不是用“没有记录”推断“没有风险”。
下面用一个明确标注为“情景模拟”的例子说明改造方法，不代表真实客户案例或行业统计。某商家有两个线上店铺、一个客服小组、一个运营小组和一名财务人员。活动期间，客服要处理咨询与售后，运营要查看活动表现，财务要核对退款和结算。团队发现多人共用一个高权限账号，且运营曾为活动临时导出客户清单。
这时我不会先建议“换 CRM”，而会先把任务拆开。客服需要按负责范围查看客户沟通与订单售后信息；运营需要汇总活动表现，未必需要客户联系方式；财务需要核对退款金额和订单状态，通常不必查看全部客服沟通内容。三组工作可能读取同一笔订单，却需要不同字段和操作。
账号清单记录账号使用人、岗位、是否共享、最后使用时间和责任人。若账号不能关联具体员工，就应标记为待整改，而不是把它当作正常账号继续沿用。
数据清单按业务需要列出订单、客户联系方式、售后记录、退款状态、活动汇总等数据，并注明哪些岗位确有必要访问。这里不应在不了解系统字段的情况下，把所有信息都贴上同一种敏感标签；要结合实际数据和业务用途逐项判断。
操作清单记录查看、编辑、导出、删除、批量修改和授权等动作，并标出高影响操作。清单不必写得像大型企业制度，但要能让业务负责人回答“谁需要、为了什么、范围多大”。
客服基础角色可以处理本人负责范围内的咨询和售后，运营基础角色可以查看活动所需的汇总数据，财务基础角色可以核对退款相关字段。若系统支持数据范围，应优先按店铺、订单归属或岗位职责限定；若不支持，则要明确这一限制，并评估是否需要由主管汇总、通过其他报表完成，或列入后续系统改造。
活动期间确实需要跨店铺支援时，可以设定限时权限，并记录活动结束日期。运营确需抽样查看客户反馈时，优先考虑按任务提供必要范围，而不是默认导出全量联系方式。若必须导出，应说明用途、字段、数量范围、保存位置和任务结束后的处理方式。
上线前，不只测试权限是否被限制，还要找真实岗位走一遍典型任务。让客服尝试处理咨询、退款和投诉；让运营完成活动复盘；让财务核对退款数据。记录每个步骤是否被权限拦住、是否需要绕行、是否出现不必要的数据暴露。
如果客服为了完成工作必须反复找管理员开权限，说明角色设计可能过窄或任务拆解不准确；如果运营无需理由就能下载所有客户联系方式，说明数据范围或导出控制仍有缺口。测试的目标不是证明配置“全绿”，而是找出安全边界与业务效率之间的真实冲突。
商家应以自己的改造前数据建立基线，再比较改造后变化。例如，盘点共享账号数量、离职账号停用耗时、临时权限到期回收情况、批量导出次数、权限相关工单和客服任务处理时长。统计周期要保持一致，并注明活动高峰、人员变化等因素，否则前后数据不具备可比性。
下面的示意数据仅用于展示如何设计度量口径，不应被引用为真实改造结果。企业实施时应以系统日志、工单记录和人员变动记录为准。
不要一开始把所有店铺、团队和外部系统同时纳入改造。可以先选一个订单量稳定、岗位边界较清楚、业务负责人愿意配合的团队或店铺。试点的目标是验证清单、角色设计、授权流程和复核动作能否跑通，而不是追求一次覆盖全公司。
试点范围应写清楚：包括哪些岗位、哪些 CRM 模块、哪些数据和哪些外部工具；暂不包括什么，也要说明原因。这样后续发现缺口时，团队能分辨是试点边界外的问题，还是方案本身遗漏。
从账号列表开始，标记个人账号、共享账号、服务账号、外包账号和管理员账号。再将系统权限导出或按界面逐项记录，与员工实际岗位对照。不要只问管理者“理论上谁有权限”，还应抽样核对员工实际能看到什么、做什么。
若系统无法提供完整的权限清单，可以先用人工表格建立最低限度的台账，记录账号、责任人、权限说明、审批人、有效期限和最近复核日期。台账不是最终技术方案，但能让责任从“大家都以为有人管”变成明确到人。
有限资源下，我会优先处理能明确降低暴露面、且不会阻断核心业务的项目。常见优先项包括：离职账号、多人共用的高权限账号、无业务理由的全量导出、管理员权限泛化、临时授权无期限，以及外部工具账号无人负责。
对低频但影响较大的权限，可先增加日志检查和负责人确认，再评估是否需要系统改造。不要为追求一次性彻底解决，而把关键售后流程全部停摆。阶段性治理的前提是缺口有记录、有责任人、有后续时间点，而不是把未解决的问题藏起来。
权限流程应与入职、调岗、离职和外包合同结束相衔接。入职时根据任务开通基础权限；调岗时先确认旧权限是否仍有必要，再添加新岗位权限；离职或合作结束时，由明确责任人发起停用和交接检查。
企业规模较小时，流程不必复杂，但必须让人事、业务负责人和系统管理员知道各自负责哪一步。例如，人事负责通知人员状态变化，业务主管确认岗位所需范围，系统管理员执行账号变更并留下记录。若没有自动化系统，邮件或工单也可以形成基本凭据。
复核不等于每个月把所有账号从头审一遍。可以按风险和变化频率分层：高权限和临时权限重点检查，普通岗位在组织变化、业务调整或定期节点复核。复核时重点问三件事：账号是否仍在使用、权限是否仍与任务匹配、例外授权是否已经结束。
检查结果要有处理状态，例如保留并说明理由、缩小范围、设置到期日、立即回收或等待系统能力补齐。若只记录“已检查”，却没有对发现的问题采取行动，复核就变成形式化打勾。
安全指标和效率指标要一起看。安全侧可以跟踪共享账号数、超期临时授权数、高权限账号数、离职账号停用时长和高影响操作记录覆盖情况。效率侧可以跟踪权限申请处理时长、权限相关工单数、典型任务完成时间和因权限不足导致的业务延误。
指标的意义是发现趋势，不是机械追求某个“优秀值”。例如权限工单下降，可能说明角色更合理，也可能是员工不再提报、转而绕过系统；导出次数减少，可能是数据需求被汇总报表替代，也可能是合法业务被堵住。需要结合业务访谈和操作记录解释变化。
这类商家通常不需要复杂的多级角色体系，但仍应避免共享高权限账号。先为每位实际使用者建立可识别的账号，区分客服处理、运营分析和财务核对等基本任务，再限制批量导出、账号管理等高影响操作。
取舍重点是不要为了“精细化”投入过多维护成本。若岗位经常变化，可以保留少量基础角色，针对特殊任务单独记录授权，而不是为每一种临时工作新增一个永久角色。
这类商家应重点设计数据范围。员工是否能看多个店铺、是否能处理非本人负责的订单，往往比角色名称更影响访问边界。可以先按店铺或渠道建立数据范围，再让岗位角色决定可执行的操作。
取舍重点是跨店支援效率与数据隔离程度。若旺季需要跨店处理，限时授权或主管分派可能比长期开放全店访问更合适；若系统不支持数据范围控制，就需要评估人工分派、数据汇总或系统替换的成本。
要把外包人员、服务账号、接口和数据交换纳入同一张清单。需要确认对方实际能访问哪些字段、账号由谁管理、合作结束后如何停用、数据文件如何交接，以及发生问题时双方怎样联系和处置。
取舍重点是服务效率与数据控制边界。外包团队可能需要在较短时间内处理大量咨询，权限不能简单缩到无法履约；但也不应因“合作多年”就默认其一直需要全量访问。应按任务、期限和合作关系复核。
先确认系统限制是配置未开启、产品方案不支持，还是接口与业务流程绕开了权限模块。短期可以采用责任人审批、受控报表、减少可导出字段、人工抽查等过渡措施，同时记录这些措施的执行成本与失效风险。
取舍重点是临时管理成本和系统改造成本。若人工审批、反复导出和权限工单已经明显拖慢业务，且关键边界无法通过现有系统实现，就应评估升级、替换或增加辅助工具的投入。不要只比较软件采购价格，还要把日常维护、培训、接口改造和业务中断成本算进去。
不要只看产品介绍中的“权限管理”四个字。应拿真实任务做演示：能否按店铺或客户归属限定数据？查看、编辑、导出能否分开配置？能否设定临时权限？关键操作是否留痕？人员离职时账号能否及时停用？导出范围能否控制？
取舍重点是功能适配程度与实施复杂度。功能越多不一定越适合小团队；如果基础权限都容易维护，操作记录也能满足管理需要，轻量方案可能更经济。反之，若多店铺、多角色、外部协作带来持续的权限盲区，则应优先评估系统能否支持清晰的数据边界和生命周期管理。
预算有限时，可先处理不依赖开发的事项：清理离职账号、取消不必要的共享账号、列出管理员账号责任人、为批量导出设置申请说明、建立人员变动通知流程、记录临时权限期限。再用一两个业务团队试点，积累权限工单、处理时长和风险事件的数据。
取舍重点是接受阶段性人工成本，但不要让临时表格成为永久盲区。手工流程要有负责人、期限和复核机制；一旦账号数量、人员流动或权限申请明显增加，就要重新评估自动化和系统能力。
许多系统都能设置角色，但实际能力可能只到菜单级。选型或续约评估时，应检查是否能分别控制模块访问、数据范围、具体操作和导出能力。还要确认配置变化是否能留痕，能否查看账号当前权限来源，是否支持按人员变动快速停用。
演示时不要只看厂商预设的标准角色。请拿自己的任务来测试，例如客服能否只看本人负责订单，运营能否看汇总数据而不接触联系方式，临时支援能否在指定日期后自动失效。真实任务比功能清单更能暴露系统是否适配。
权限功能的价值不仅是上线时配置，还包括日常维护。需要确认系统能否导出账号清单、查看权限变更记录、查询关键操作日志、识别长时间未使用账号，以及支持权限复核。若这些动作全靠人工逐页截图，长期维护成本可能远高于初始采购时的估算。
同时要核实日志能记录到什么程度、保存多久、哪些角色可查看、能否导出，以及是否覆盖外部接口或批量任务。系统记录范围有限时，应将缺口写入评估结论，不要把“有日志”理解成“所有关键操作都可追溯”。
选型试点可选择三类任务：一个日常高频任务、一个高影响操作、一个岗位变化场景。比如客服处理售后、运营申请一次有限范围的数据导出、员工调岗后收回旧权限并添加新权限。观察每个任务是否顺畅、是否有记录、能否解释权限来源。
如果供应商无法现场演示某项能力，应记录为待确认，而不是默认产品具备。合同、服务说明和实际配置还应保持一致；涉及数据处理、第三方接入或责任分工时，结合企业具体业务与适用要求审查。
电商 CRM 权限改造不必从一次大规模系统替换开始。中小商家可以先找出最难解释的几项授权：谁在使用共享账号、哪些人能够批量导出、管理员权限由谁持有、临时权限何时到期、人员离职后谁负责停用。能回答这些问题，才算开始建立权限边界。
下一步可以选一个客服或运营团队，完成“账号，数据，操作”三张清单；随后挑一个高频任务和一个高影响操作做权限测试。把任务处理时长、权限工单、超期授权和账号清理情况记录为基线，再根据试点结果调整角色与流程。
我的核心判断是：好的权限设计，不是让每个人都少做事，而是让每个人只需要得到完成工作所必需的能力，并且让例外有期限、变化有记录、问题有人负责。先把边界说清楚，再决定需要多少系统改造；这比先堆角色、买功能、最后再问业务为什么绕过系统，更适合资源有限的中小商家。
我准备整理CRM权限，但系统里有客服、运营、仓库和外包人员，光看岗位名称似乎很难判断谁该看什么。我应该先买新系统，还是先盘点现有账号和业务流程？
建议先盘点，不要一上来就换系统或重建复杂角色。选一个订单处理团队，记录每类人员在接单、售后、退款、客户回访时需要查看和执行的操作，再对照现有账号逐项核对。可以先做三张清单：人员与账号、可访问的数据范围、可执行的操作。比如客服可能需要查看负责订单的联系记录，但不一定需要导出全店客户名单。
先找出共享账号、离职未停用账号和全量导出权限，再评估系统是否确实缺少必要控制能力。
我现在给客服和运营分别建了角色，但还是担心权限边界不清。比如客服能看订单，是不是就意味着能看所有店铺的订单，也能批量导出客户信息？
这三者解决的是不同问题：角色回答“这个人属于哪类岗位”，数据范围回答“他能看到哪些记录”，操作权限回答“他能对记录做什么”。只按岗位建角色，容易出现客服只能处理本店售后却能检索全店客户，或能查看订单也能批量导出的情况。
配置时可把“查看、修改、删除、导出、授权”分开核对，再按店铺、订单归属或业务团队限制数据范围。对批量导出、删除和权限变更等影响较大的操作，可结合系统能力设置审批、限时授权或操作记录。
我担心一改权限，一线人员就看不到处理售后所需的信息，最后只能找管理员临时开权限，甚至回到共享账号。有没有既能控制风险又不耽误日常工作的推进方法？
改造前先选一个团队试运行，用真实任务验证权限，而不是只检查配置页面。例如让客服完整演练一次查单、联系客户、登记售后和申请退款，记录在哪一步因权限不足而停住，再区分是角色配置错误还是数据范围设得过窄。可以按“盘点账号，列出任务和数据，配置基础角色，小范围试运行，处理例外，推广复核”的顺序推进。
临时项目或外包任务尽量采用有申请人、用途和到期时间的授权；不要为了减少求助，把管理员权限长期开放给一线岗位。
我不想把权限改造做成一次性的配置任务，也不确定该用什么指标向团队说明结果。除了检查有没有违规访问，还能不能衡量权限管理是否真正可执行？
先建立自己的改造前基线，不要直接拿未经核实的行业平均值比较。可跟踪未明确归属或已停用账号数量、权限复核完成率、临时授权按期回收情况、关键操作日志覆盖情况，以及离职账号从通知到停用的处理时长。还要同时观察业务影响，例如因权限不足产生的工单数量和订单处理延误。
假设某团队试运行后，发现客服无法查看必要的售后记录，就应修正数据范围，而不是只追求权限更严。指标口径和统计周期要固定；涉及个人信息或外部数据共享时，再结合实际业务与适用规则核验要求。
读者评论
把权限拆成身份、数据范围和操作类型来梳理，比单纯增加角色更容易发现客服查单、批量导出等需求之间的差别。
文中对临时授权遗留和共享账号的提醒很实用。设定到期时间还应明确谁负责回收，否则流程容易停在申请和批准。
限制导出不能覆盖接口、插件和人工复制等数据流转路径，这一点值得纳入改造清单；同时也要保留必要业务的受控导出。