结论先行：AI 排先后依据的是时间戳顺序，而时间戳本身的误差常常比两次故障的真实间隔还大——时钟不同步时，排出来的先后首先是“记录顺序”，不一定是“物理顺序”。楼上已经把对时、双时间戳、不确定度讲得很全了，我补一个现场能直接用的角度：先给不同步定性，再按顺序排查，最后把结论写成维修不会误读的样子。一、先定性：三种不同步，修法不一样1. 固定偏移：每次对表都差一个固定值，比如恒差 8 秒。常见原因是时区配错、夏令时，或某台设备上次对时失败。修法：统一时区配置，重新对时一次；历史数据可以用这个固定值整体平移修正。2. 持续漂移：差值越跑越大，每天多几秒。常见原因是晶振老化、温度变化，或设备长期没有对时。修法：缩短对时间隔，老设备考虑换高稳晶振，或在网关侧统一重打时间戳。3. 跳变：重启、固件升级或手动校时后，时间突然跳了一下。修法：先确认跳变点前后各一段数据的可信度，跳变点附近的数据单独标注，不要和前后混着排。定性方法很简单：在设备和网关上各执行一次 date，隔 10 分钟再执行一次——差值不变是固定偏移，差值变大是漂移；再查重启和校时记录，看故障时段前后有没有跳变。二、现场排查清单（按顺序做，别跳步）1. 对表：各设备和网关同时执行 date，记录差值；10 分钟后再对一次，判断是固定偏移还是漂移。2. 查同步状态：执行 chronyc tracking，看系统时间的偏移量和上次同步时间；再执行 chronyc sources -v，看每路时间源是否正常。偏移超过 500ms，先修授时，再谈模型。3. 查跳变记录：重点看故障时段前后有没有重启、固件升级或手动校时，跳变点附近的数据先标为存疑。4. 找共同事件验证：用一次断电、一次启停这类所有设备都能感知到的事件，对齐各路记录，算出真实的相对偏移，和第 1 步的判断互相验证。5. 核对时间戳语义：确认每路数据的时间戳是采样时间、组包时间还是接收时间——三者混用时，先统一口径再排序，否则对时对得再准也排不对。三、诊断结论要这样写，维修才不会被带偏AI 的输出不能只有一个“谁先谁后”，要同时带上三样东西，缺一个都别派单：1. 顺序结论加置信度：写“振动先于温升（间隔 4 秒，总不确定度约 6 秒，顺序不可信）”，而不是只写“振动先于温升”。2. 时钟健康：每条诊断附上当时的时钟偏移量和上次对时时间，写进报告正文，不要只记在日志里。3. 下一步动作：如果顺序不可信，下一步写“先修授时、重采数据”，而不是“先换轴承”——顺序错了，维修方向就全错。时钟没修好之前，结论只能写“同时段异常”，不要写“谁先谁后”。四、长期：让时钟偏移变成日常监控，别等出事才查把 chrony 的偏移量和同步年龄接进监控（比如 CES 自定义指标），设两档阈值：偏移超过 200ms 告警、超过 1 秒直接把该时段的诊断结论降级为“顺序不确定”，不自动派单。这样下次再出现误判，值班第一时间看到的是时钟告警，而不是一份方向反了的根因报告。一句话：时钟要修，但修之前先把“顺序到底可不可信”算清楚、写清楚——按固定偏移、漂移、跳变先定性，排查按对表、查同步、查跳变、找共同事件、核时间戳语义的顺序做，诊断单上带上置信度和时钟健康，偏移量进日常监控，AI 的先后结论才敢拿去指导维修。

小程序端不能直接用 OBS 的服务端 SDK（Node.js/Python 版），原因有两个：小程序运行环境没有 Node 模块加载能力；更重要的是 AK/SK 绝不能写进小程序代码——小程序包可以被反编译，永久密钥一旦泄露，别人就能直接操作你的桶。推荐两种做法：第一种，经过自有后端中转（最稳妥）：小程序用 wx.chooseMedia 选文件，再用 wx.uploadFile 发到自己的后端（ECS 上跑的服务或者 FunctionGraph 函数都行），由后端拿着 AK/SK 调用 OBS SDK 上传。密钥只在服务端出现，小程序侧完全不碰，权限也最好控制。第二种，小程序直传 OBS：后端先签发临时授权再让小程序直接上传，有两种签发方式：（1）用 STS 方式获取临时 AK/SK 和 SecurityToken，设置好过期时间，并限定只能操作指定桶和指定对象前缀；（2）生成 POST 上传用的 policy 和签名（signature），小程序拿到后直接 wx.uploadFile 到桶域名。两种方式都要在后端做，临时凭证用完即过期，即使被截获影响也有限。下载和访问则简单得多：公开读的桶直接用对象 URL；私有桶让后端按需签发带签名的临时 URL（比如有效期 3600 秒），小程序用这个地址展示图片即可，不用把桶设成公开。另外两个容易踩的坑：小程序管理后台要把桶域名加到 request 合法域名和 uploadFile 合法域名里，否则请求会被拦截；上传前在后端做好文件类型和大小校验，别让小程序直传通道变成任意文件上传口。一句话总结：密钥和签名放后端，小程序只拿临时凭证做上传和带签名的临时链接做访问。

补充一个前面回答较少提到的角度：密钥和密码同时被拒，先别急着改 sshd 配置，用控制台 VNC 进去查账号状态——账号被锁定、过期或被设为不可登录时，两种凭证都会被拒，改配置改不到点子上。1. 看账号是否被锁定或过期（VNC 里执行）：sudo passwd -S 用户名   # 出现 LK 表示账号被锁定sudo faillock --user 用户名   # 部分镜像连续失败会临时锁定；确认后解锁：sudo faillock --user 用户名 --resetsudo chage -l 用户名   # 看密码是否过期、账号是否过期grep 用户名 /etc/passwd   # 看登录 shell 是不是 /sbin/nologin 或 /bin/false，是则账号本身不允许登录ls /etc/nologin   # 这个文件存在时，除 root 外所有普通用户都会被挡在登录之外2. 确认密钥和密码各自的失败面不同：密钥对创建的实例，root 初始没有密码——密码登录必然失败，这时不是密码错，而是没有密码。正确做法是控制台“重置密码”并按提示重启生效，再核对 PasswordAuthentication 是否放开。3. 注意云上特有的两个坑：- 换绑密钥对、重置密码后，实例需要按控制台提示重启/重置才会把新配置写进去，只点绑定不生效；- 如果实例做过重建、恢复或换过自定义镜像，authorized_keys 可能被 cloud-init 重置，旧公钥失效，需要重新绑定当前密钥对。如果以上账号状态都正常，再按前面的回答去核对 authorized_keys 内容和 sshd 生效配置；日志以 /var/log/secure（CentOS 系）或 /var/log/auth.log（Ubuntu/Debian 系）为准。

先给一个能直接套用的判断标准：触发是不是事件或定时、单次能不能在几分钟内做完、有没有常驻状态、流量是不是波动大。这四个问题里前三个答“是”、最后一个是“波动大或低频”，FunctionGraph 就大概率是合适的；反过来，需要常驻进程、长连接、跑几十分钟的，就别硬塞进函数里。 一、最适合的六类场景 1. 文件到了就处理（事件驱动）。这是最典型的用法，我实测过一条链路：用户上传原图到 OBS 源桶 → OBS 事件触发函数 → 函数下载原图、用 Pillow 生成缩略图 → 上传到目标桶 → 写一条处理记录。没有常驻进程，不上传就不花钱，上传高峰自动并发扩容。注意两点：源桶和目标桶一定要分开，否则缩略图写回源桶会再次触发函数、自己触发自己；处理逻辑要幂等，按原图 key 生成固定缩略图名，事件失败重试时才不会重复入库。 2. 轻量 Web/API 后端。通过 APIG 暴露 HTTP 触发器，接签到、表单提交、第三方 webhook 回调、短信验证码回调这类接口：先做签名校验，再转存或落库。低频或波峰波谷明显的业务很划算，平时没流量不花钱。 3. 定时任务和运维自动化。每天凌晨跑一次：清理过期对象、汇总前一天数据生成报表、巡检证书和资源到期、备份后发通知。配一个定时触发器就行，不用为巡检常年养一台 ECS，跑完即停。 4. 消息流处理。配合 Kafka、DIS、LTS：订单消息、日志消息进来，函数逐条消费，做校验、格式转换、脱敏、入库或告警分发。流量忽高忽低时自动扩容，积压时把并发上限调高即可；但注意消费失败重试要和幂等一起做，否则同一条消息会重复入库。 5. 轻量 AI 推理和回调。图像分类、OCR 后处理、文本抽取这类“一次请求、几秒出结果”的推理，函数里调用模型服务或加载小模型都合适；大模型训练、长时间推理、模型文件几 GB 的，别放函数里。 6. 系统间胶水/ETL。把多个云服务串起来：LTS 日志告警 → 函数 → 发企业微信/短信；定时把 RDS 的增量数据抽到 OBS 做归档。代码量小、改动频繁，用函数比单独部署一个服务省事。 二、不适合的四类场景 1. 常驻服务、长连接、WebSocket。函数执行完就回收，没有一直在线的进程，靠它维持长连接会反复冷启动、连接还总断。 2. 单次执行几十分钟的批处理。函数有超时上限（最长 900 秒），超过就被系统杀掉；大批量、跑一夜的数据任务，还是走容器或 ECS。 3. 强状态、本地大文件、复杂本地环境。函数执行环境是临时的，写到本地磁盘的东西下次不一定还在；依赖特殊内核、GPU、大内存的，也不合适。 4. 7×24 小时持续高并发的核心接口。一直满载跑的时候，按调用量和 GB-秒计费可能比一台 ECS 更贵，延迟上冷启动也不占优，这时选常驻服务更划算。 三、上手建议：先小后大 新手建议先拿一个定时任务或一个 OBS 缩略图函数跑通全流程，再放量。先在控制台用“测试事件”跑通，再开触发器；出问题先去 LTS 看函数日志，403 先查 IAM 委托、连不上内网先查 VPC 接入和安全组，超时先看单次执行能不能拆小、内存给够没有。 一句话：触发是事件、一次几分钟内做完、无状态、低频或波动大，就优先 FunctionGraph；需要常驻、长连接、长耗时，就选 ECS 或容器。 

结论先行：桶保持私有，用预签名 URL 分享，AK/SK 只留在自己这边。上面几位把原理讲得很全了，我补一个能直接照着落地的版本：三种签发方式的适用场景、‘签了名还打不开’的排查顺序，以及审计和止损分级。 一、三种签发方式，按场景选1. 一次性人工分享、没有后端：OBS 控制台进桶找到对象，在对象详情里生成临时 URL，设好过期时间后把链接发给对方。适合偶尔发一两个人，不适合批量。2. 命令行或脚本：自己机器上配好 obsutil 后执行 obsutil sign obs://桶名/对象路径 -e 1800，1800 是秒（30 分钟）。配置文件里有 AK/SK，千万别发给别人。3. 业务系统自动签发：对方先向你的业务接口申请下载（可先做登录身份校验和审批），后端再用 SDK 对 GetObject 签名，只把链接返回给对方。Python SDK 大致是：ObsClient(access_key_id=AK, secret_access_key=SK, server='obs.cn-north-4.myhuaweicloud.com')，再调 createSignedUrl('GetObject', '桶名', 'partner/report.pdf', expires=1800)。签发建议用专用 IAM 用户，只给该前缀的 obs:object:GetObject，不要用主账号 AK/SK。 二、有效期和权限粒度，按你的三个问题能控制的：一个对象 + 一个操作 + 一个过期时间。签 GetObject 只能下载，不能上传、删除、列桶；换个对象链接就失效。签名时带上 response-content-disposition=attachment，可以让浏览器强制下载而不是直接预览。控制不了的：链接本身不限人、不限 IP、不限次数，有效期内谁拿到都能下载，也能转发。需要限人、限次数、留审计记录，就走后端代理转发：对方先登录你的业务系统，后端校验完再从 OBS 取对象流式转发；固定合作方长期下载，则用桶策略或 IAM 策略给对方账号授予 obs:object:GetObject 并限定到具体前缀。时间给多少：内部临时分享 15~30 分钟足够，别默认给几天；文件大、对方外网下载慢时再适当放宽。 三、链接泄露了怎么止损（由轻到重）1. 等过期：短有效期本身就是止损，窗口只有十几分钟。2. 对象改名或换前缀：旧链接立即 404，最快最彻底，适合单个链接泄露。3. 轮换签发用的 AK/SK：该密钥签出的所有链接同时失效，适合大面积泄露，之后记得更新服务端配置并重发链接。4. 事前加固：敏感目录叠加桶策略 IP 白名单，泄露的链接在白名单外也打不开；敏感文件单独放一个前缀，出事只换这一个前缀。 四、签了名还打不开，先按这个顺序查（最容易漏）1. 先确认链接是不是过期了，有效期从签发时刻算；2. 用 curl -v 打开，看返回的错误码和响应头，先区分是签名问题还是权限问题；3. 检查签发 AK 的权限：有没有该对象的 GetObject，有没有被桶策略或 IAM 策略显式拒绝；4. 检查对象名和区域 endpoint 有没有写错，对象不存在时 OBS 也常返回 403 而不是 404；5. 走了 CDN 加速域名时确认 CDN 回源透传了签名参数，有些‘链接打不开’是 CDN 把 query 丢了；6. 前端直连下载要在桶的 CORS 规则里放行业务域名。 五、审计别忘开临时链接本身不留‘谁下载了’的记录。需要审计时，开启 OBS 访问日志或用云审计 CTS 记录签发和下载行为，至少能查到‘哪个 AK 在什么时候签发了哪个对象’。 一句话总结：一次性分享走控制台或 obsutil 生成短有效期预签名 URL；系统对接走后端 SDK 签发；固定合作方、敏感内部资料改用桶策略、IAM 精确授权或后端代理，桶始终保持私有。

楼上 3 楼、7 楼、10 楼已经把权限、存储类别、生命周期这些大坑讲得很全了，我补充两个新手最容易忽略、楼上没展开的点。一、桶名全局唯一，建桶前先想好命名。OBS 的桶名在整个系统内唯一，且桶建好后不能改名、不能改区域。新建测试桶时别随手起个名字，生产桶建议按“业务-环境-用途”定好命名再建，省得以后要迁移。二、OBS 的对象是不可变的，没有“追加写”。日志类场景最容易踩这个坑：想把日志一行行追加到同一个对象里是做不到的，每次追加都要重新上传整个对象。正确做法是先在 ECS 或消息队列里聚合，再按小时或天批量上传成新对象；跑完再用生命周期规则把冷数据沉降下去——这个思路我之前写过一篇 OBS 生命周期降本的实战，冷数据自动降级确实能省不少。新手第一天建议：先建一个测试桶，把“私有桶 + 临时签名 URL + 生命周期（沉降与清理碎片）+ 版本控制 + 删桶前清空”这套组合完整跑一遍，再往生产桶里放真实数据。

前面几楼把适合与不适合的场景分得很清楚了，我补充一个可以直接照着跑的最小落地例子，这是 FunctionGraph 最典型的形态：OBS 图片上传自动生成缩略图，全程没有一台常驻服务器。一、链路长这样用户上传图片到 OBS 原图桶 → OBS 事件触发函数 → 函数下载原图、用 PIL 生成缩略图写回缩略图桶，同时把图片元数据写进 RDS。每天凌晨再由 Timer 触发器跑一个清理函数，删 30 天前的临时文件。二、创建时照这几步配1. 创建函数：运行时选 Python，内存 512MB，超时 60 秒（单张图几秒就够；大图再适当放宽，超时最长可配到 900 秒）。2. 建 OBS 触发器：事件类型选 ObjectCreated:Put，源桶填原图桶，可以加对象名前缀 uploads/ 和后缀 .jpg 做过滤。3. 权限：给函数配一个 IAM 委托，授予 OBS 的读写权限，否则触发器调用函数会报权限不足。4. 代码里注意两点：文件要下载到 /tmp（函数实例的本地临时目录），处理完及时清理；生成缩略图的关键日志要打出来，失败的调用才能定位到是哪一次触发。三、两个容易忽略的点1. 触发是异步的，同一个上传事件失败后平台会重试，函数要按“同一事件可能来两次”来写：写 RDS 前先查重，或者用对象名做唯一键去重。2. 依赖别贪大：PIL 这类库能精简就精简，部署包直接上传上限 50MB，超过要走 OBS 上传部署包；包越大冷启动越慢。按这个链路跑通一次，定时汇总、短信通知、文件清洗这些活都可以照着同样的“事件 → 函数 → 下游服务”模式接进来。

先说结论：df 和 du 的口径本来就不一样，差额一定有归属。楼主已经查过 lsof 没发现明显问题，建议按“先对齐 du 的统计口径，再找 du 看不见的空间”这个顺序查，重点查第 2、第 3 类。一、先确认是哪种“满”df -h 和 df -i 一起看：df -hT /data; df -i /data块满了是 df -h 到 100%；inode 耗尽是 df -i 到 100%，表现常常是“df -h 还有空间却写不进文件”。两种“满”原因完全不同，先分清再往下查，别把 inode 满当成大文件来找。二、把 du 的口径对齐，很多人第一步就漏了1. 用 root 跑。sudo du -x -h --max-depth=1 /data，非 root 跑 du，权限不足的目录会被静默跳过；如果把错误输出丢到 2>/dev/null，漏了哪都不知道。2. 加 -x 限定在同一个文件系统内，否则 du 会跨进别的挂载点一起算。3. 不要用 du -sh /data/* 这种写法：shell 的 * 展开会漏掉隐藏目录和隐藏文件（比如 /data/.cache、/.snapshot），直接对 /data 本身统计：sudo du -x -sh /data。4. 用同一单位对比：df -B1 /data 和 sudo du -x -B1 -s /data 都用字节，再看差额是多少 GB。三、按顺序找“du 看不见”的空间1. 已删除但仍被进程占用的文件lsof 没查到，可能是输出太多被淹没了，或者文件在容器里被删、宿主机 lsof 看不见。换两个姿势再查一次：sudo lsof +L1sudo find /proc/[0-9]*/fd -lname '* (deleted)' -printf '%p -> %l\n' 2>/dev/null | head -20容器里的情况，用 nsenter -t 容器主进程 PID> -m -p lsof +L1 进容器命名空间查，或 docker exec 进容器查。确认后不用重启进程，用 : > /proc//fd/ 把内容截断，空间立即释放。2. 挂载点把旧数据盖住了典型场景：先往 /data 写了几十 GB，后来又把一块云硬盘挂载到 /data 上，旧文件还占着父文件系统的空间，但 du 走的是挂载后的目录树，看不见了。验证不用 umount：sudo mkdir -p /mnt/rootview && sudo mount --bind / /mnt/rootviewsudo du -sh /mnt/rootview/data如果这里看到 du 之前统计不到的几十 GB，就是它。也可以先 findmnt -R / 看完整挂载树找可疑挂载点。3. ECS 上最容易灯下黑的隐形占用journalctl --disk-usage 看 /var/log/journal，经常攒到几个 GB；跑了 Docker 就看 /var/lib/docker/containers/*/*-json.log，没有轮转时单个能涨到几十 GB，docker system df 是看不到容器日志大小的；再看 /tmp、/var/tmp、/var/crash 和 coredump。4. ext4 预留块和文件系统元数据tune2fs -l /dev/xxx | grep Reserved 看预留块，ext4 默认给 root 预留 5%。注意它解释的是“Avail 比 Used 小”，不是“Used 比 du 大”，别把两者混淆。元数据占比通常不到 2%，差额几十 GB 时凶手不是它。四、对账公式df 的 Used ≈ du -x 的总计 + 已删除未释放 + 挂载点遮挡 + 预留块。按上面 1→4 查一遍，差额超过 5% 一定还有漏项，回到第二步检查 du 的执行身份和 -x。五、根治日志加 logrotate 并用 copytruncate，不要直接 rm 运行中服务正在写的大文件；journald 设 SystemMaxUse=200M；Docker 在 /etc/docker/daemon.json 里配日志轮转（max-size 50m、max-file 3）；再给磁盘使用率配 CES 告警，80% 预警、90% 告警，别等到 100% 再查。

先说结论：你的理解基本都对，40 分钟延迟的根因就是单个事务在从库上无法并行回放。下面按你的五个问题逐条给可落地的结论，重点补一个带自适应节流的拆分方法和事前检查清单，1、2 楼已经讲过的部分不再重复展开。一、并行复制对单个大事务确实没用LOGICAL_CLOCK 按事务提交顺序的锁区间分组，WRITESET 按事务写过的行哈希分组，分组单位都是事务。一个 31 万行的事务自成一组，从库只能由一个 applier worker 串行回放。WRITESET 只在多个事务之间起作用，同一个事务内部没有并行可言，这个结论不需要再验证。二、binlog_row_image=minimal 能减体积，但要先确认下游这条 UPDATE 只改 status，没有改主键和唯一键，minimal 下 before image 只记录主键，after image 只记录被改的列，binlog 体积通常能降一半以上。但它改的是行镜像的内容，下游 CDC（Canal、DTS 订阅）、binlog2sql 闪回都可能受影响。没有这些下游再开；RDS 上改这个参数走参数模板，需要重启生效，不要在业务高峰改。三、推荐的拆分写法：按主键区间加自适应节流5000 行、sleep 50ms 是合理起点，但更好的做法是让等待时间跟着从库延迟走：每批 UPDATE 带上 WHERE id 大于上批最大 id、小于等于上批最大 id 加 5000，并且带上 AND status=1，保证重复执行幂等，中断后续跑；每 10 批查一次从库 Seconds_Behind_Master，大于 10 秒就暂停，直到追到 5 秒以内再继续；把已处理的最大 id 写进一张控制表或文件，中断后续跑不用从头来。不要用 LIMIT 翻页：无 ORDER BY 时边界不稳定，越翻越慢，还可能漏改或重改。执行前后用 SELECT COUNT(*) WHERE status=1 对账，确认改的总行数和预期一致。四、Seconds_Behind_Master 在大事务期间会偏小它的值是当前时间减去正在回放事件的时间戳。从库卡在一个大事务里时，事件时间戳就是事务开始的时间，差值一直不动，看着像没有延迟；等事务一提交，差值才突然跳起来。更可靠的办法是在主库建一张心跳表，每秒写一条带时间戳的记录，在从库读这条记录算真实延迟；同时看 Relay_Log_Space 的堆积量，relay log 持续上涨说明回放跟不上。五、确实要一次性改大量行时的选择数据订正这类场景，优先级是：分批脚本加幂等条件加进度可续跑，绝大多数情况这就够了。如果表结构也要一起改，用影子表：建新表、按主键分批 INSERT SELECT 写入（同时把 status 转换过去）、对账、rename 交换，交换瞬间需要短暂锁表，要在低峰做。DTS/DRS 适合跨实例、跨库的整体迁移，不适合单表订正；gh-ost、pt-online-schema-change 是改表结构用的，不解决 DML 大事务。六、为什么控制台没有告警RDS 控制台的复制延迟指标取自 Seconds_Behind_Master，采集粒度是分钟级。大事务期间这个指标被低估，等它跳变时延迟已经快追平了。建议自己加两条告警：心跳表延迟超过 10 秒、relay log 空间持续上涨。这样下次就是监控先发现，而不是业务先反馈。

补充几个前面回答提及较少、但新手很容易踩的检查点。 一、密钥和密码分开测，不要混着ssh -o PreferredAuthentications=publickey -i /path/to/key 用户@IPssh -o PreferredAuthentications=password -o PubkeyAuthentication=no 用户@IP密钥能通、密码不 → 只查密码这条线（创建实例时选密钥对登录，root 通常没有设置密码，最常见）；密码能通、密钥不通 → 只查密钥这条线（authorized_keys、权限、指纹）。两条都失败，再看账号和 sshd 配置。 二、公钥可能落到了别的用户家目录控制台导入的公钥，只会写入创建实例时指定的那个系统 ~/.ssh/authorized_keys。Ubuntu 是 ubuntu、CentOS 是 root，但部分市场镜像、自定义镜像的默认用户是 ecs-user 或其他。VNC 进去后：ls -l /home/*/.ssh/authorized_keysls -l /root/.ssh/authorized_keys看看公钥到底在哪个用户下面，再用对应的用户名登录。 三、账号本身被锁或cat /etc/passwd | grep 用户名   # shell 是 /sbin/nologin 或 /bin/false 就登不进passwd -S 用户名               # 锁定状态会显示 LKgrep -E 'AllowUsers|DenyUsers' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf 四、端口可能被改ss -tlnp | grep sshd 看实际监听端口；如果改过端口，ssh 要加 -p 端口号，22 通不代表 sshd 就在 22 上。 最后提醒：反复试密码可能 pam_faillock 临时锁账号，先停一会儿再测，或者直接用控制台重置密码、更换密钥对恢复。触发过  禁登  用户的通试