鸿蒙冒险大转盘实战：转盘同局去重设计与 AI Shell 排查 ECS 磁盘满

今天在鸿蒙开发实践中心浏览了“冒险大转盘：用 AI 构建鸿蒙元服务”案例，并给它的 GitCode 代码仓 harmony-practice-center/HarmonyOS-AtomSer-AdventureWheel 点了 Star；随后在 AI DevSpace 的 AI Shell 里问了一个新问题：一台正在运行的 ECS 实例系统盘快满了、业务不能停机，怎么定位、清理和扩容。这篇笔记把两件事合在一起写：一边是端侧元服务的状态与动画设计，一边是云端实例的磁盘排障。看起来是两个方向，道理是相通的——先把状态看清楚，再动手。

一、大转盘案例：先定结果，再算角度

这个案例是一个纯本地的鸿蒙元服务：朋友聚会时选好玩法与挑战程度，生成一张大转盘，轮流点击抽取任务，内置 190 条任务，目标 API 23、最低兼容 API 20。

它最值得学的一点，是把随机结果和转盘动画彻底分开。正确顺序是：先从尚未处理的任务中随机选定目标，再根据目标所在的扇区计算停止角度，最后让转盘先快后慢地减速、停稳在对应扇区，突出命中扇区并展示居中的结果卡片。反过来做——先转再看停在哪——指针和结果就对不上号，体验立刻穿帮。

转盘的 2.5D 效果来自 Canvas 绘制的侧壁、阴影和透视变换，配合属性动画实现减速。动画期间要禁止重复点击，否则一次转动里混进第二次随机，状态就乱了。案例还提醒：转盘不用于博彩或需要审计的抽签，完成状态只属于当前一局。

二、同局去重与交接状态

聚会游戏最怕重复抽到同一个任务。案例的做法分三层：开局前先筛选、再做无重复随机抽样组成清单，自定义任务最多占本局数量的一半；点击“立即开始”后先看本局清单，不满意可以“重新生成”，确认后才正式开局；开局后每次只从尚未处理的任务中选取。

抽到结果后点“交给下一位”，当前任务变灰并标记“完成”，本局不会再抽到；不想做也可以交接跳过；最后一项抽完显示“完成本局”。这套状态机很干净：任务只有“待处理”和“已处理”两种状态，交接就是一次状态转移，剩余数量随之递减，数一数就能验算。

三、本地持久化与文件迁移

这个元服务没有服务器、不自动云同步，数据全在本地：内置任务随工程打包，自定义任务与首页设置用 Preferences 保存。自定义正文去首尾空白后必须非空、最多 30 个 Unicode 字符，输入、保存和导入用同一套校验规则。

迁移靠文件：导出自定义任务为 JSON，或通过“分享我的任务”生成 TXT，TXT 正文仍是 JSON，新设备导入可以恢复。契约要记牢：单份自定义文件最多导入 1000 条、大小不超过 1 MiB；导入时先统计再确认，只合并新任务，非法文件不写入；备份超限时用工程附带的安全拆分工具逐份导入，恢复前先核对。分享前要检查敏感内容，清除数据、卸载或换设备前先导出并验证恢复。

四、AI Shell 实问：运行中 ECS 系统盘满了怎么办

今天在 AI Shell 里提的问题是：“运行中的 ECS 实例系统盘快满了、业务不能停，怎么定位哪些文件占了空间、哪些可以安全清理、清理不够时如何在线扩容？”AI Shell 给出的回答分“定位—清理—扩容”三个阶段，全程不需要停机。

定位先看整体，再逐层钻取：

1. df -hT——看各挂载点容量、已用、可用与使用率，确认哪个分区满了、文件系统类型是 ext4 还是 xfs；
2. sudo du -h --max-depth=1 / 2>/dev/null | sort -rh | head -20——逐层定位，从根目录开始，看到哪个目录大再往下钻；
3. sudo find / -xdev -type f -size +500M -exec ls -lh {} \; 2>/dev/null | sort -k5 -rh | head -30——快速找出大于 500MB 的大文件，-xdev 表示不跨文件系统；
4. sudo lsof +L1 2>/dev/null | awk '$7 > 104857600' | sort -k7 -rn | head -20——找出被进程持有但已删除的大文件；
5. sudo journalctl --disk-usage——看 systemd 日志占了多少空间。

其中 lsof +L1 是最容易被忽略的一步：文件被 rm 删了，但进程还握着文件描述符，空间并不会释放。对这类文件不要重启进程，用 > /proc/<pid>/fd/<fd号> 清空内容即可释放空间。

清理只动认识的、能确认安全的内容，不确定的先 mv 到别处观察，不要直接 rm。按优先级：journal 日志用 journalctl --vacuum-time=3d 只保留最近三天；包管理器缓存 yum clean all；旧内核 package-cleanup --oldkernels --count=1 -y；/tmp 只删 7 天前的文件；Nginx 这类日志用 truncate -s 0 清空而不删除文件。绝对不要碰的目录：/etc、/boot、/var/lib/mysql 等数据库数据文件、/proc 与 /sys、/usr。

清理后还不够就在线扩容，分两步：先在控制台把 EVS 系统盘扩容（比如 40GB 扩到 80GB），这一步不停机；再进系统内确认并扩展。lsblk 看新大小，必要时 echo 1 > /sys/block/vda/device/rescan 或 partprobe 刷新；分区用 growpart 扩展，ext4 用 resize2fs、xfs 用 xfs_growfs（xfs 只支持扩不支持缩）；最后 df -hT 验证。扩容前建议先给磁盘打个快照，几秒钟的事，万一操作失误可以回退。

五、两件事的共同点：先看状态，再动手

写大转盘时，指针错了先查“先定结果还是先转动画”；查 ECS 磁盘时，空间没释放先看 lsof。两边都在做同一件事：把当前状态变成看得见的东西，再基于它做决策。端侧的 Preferences 状态和云上的 df 指标，角色是一样的——状态不清就动手，最容易误伤。

今天的收获有两点。第一，小应用里藏着完整的工程思维：随机与动画分离、状态机去重、带契约的文件迁移，每一步都能单独验证。第二，云上排障有一条固定顺序——定位、清理、扩容，每一步都有可验证的完成标志，跳过任何一步都容易误判。接下来我打算照着大转盘案例的完整实践路线，从空项目开始自己搭一版，再把磁盘巡检的几条命令写成固定检查清单。