首次使用与清空后的空态含义不同
别名: 空态来源 · first-run vs cleared · 从未有过与删光
概念解释
画面同是零条，原因却把空分成不同的对象。空态来源（empty-state provenance）要求交付至少分开两种：这个容器从未有过内容（首次），和曾经有过、被用户或系统拿光（清空后）。首次在解释「这里是什么、第一件如何出现」；清空后在承认「东西刚才还在」，并指向找回、撤销或再导入。把两种做成同一张欢迎插画，清空的人会被当成新用户，从未用过的人会被提示去回收站。
来源是空帧要携带的身份，不是列表基数为零时行头还在不在——那是另一组几何问题。两种来源都可以有引导，但引导的句子和动作不能共用。
机制
人对空的解释依赖刚刚发生过什么。从未有过的空，工作记忆里没有「上一份列表」，欢迎和创建是匹配的。刚删光或刚断开同步的空，工作记忆里还有那些对象，欢迎语会被读成系统把历史吞了；此时需要的是时间线索（「你刚才删除了 12 项」）和可逆动作。实现若只拿到一张空帧，就只能接一个模板，通常是设计文件里出现过的那张首次欢迎。于是清空路径在运行时被错贴上「开始使用」，撤销入口因为帧上没有而被漏接。
来源还决定空能不能自动消失。首次在第一件创建成功后必须撤掉，否则欢迎会和真列表抢版面。清空后的空应在撤销窗口内保留那条找回，窗口关闭后再收敛成稳定的「现在是空的，可以再创建」。一张共用帧无法表达这两种寿命，实现会选一种寿命套到所有零上。
边界
筛选、搜索把十条收成零条，来源是查询，不是首次也不是清空；应走「无匹配 + 改条件」，不要借用欢迎，也不要借用撤销删除。加载失败不是任何一种空的来源，失败帧必须能和这两种空互相区分。多容器产品里一个面板是首次、另一个已被清空，要按容器分别交付，不要因为页面上「还有一个空」就弹全局欢迎。演示数据、样例项目填满了工作区时，首次来源在真实账号上才出现，交付仍要给真实账号留首次帧，不能用演示截图冒充。
怎么落地
- 为同一容器交出两帧，帧上用条件写明：
never_had_items与had_items_now_zero（含用户删除、归档、解除绑定等子原因若动作不同，再拆帧）。 - 首次帧禁止出现回收站、撤销、或「恢复上次」；清空帧禁止出现「欢迎使用」「这是你的工作区」。
- 为清空帧标注撤销窗口有多长、窗口外还留不留找回入口；为首次帧标注第一件成功后哪一层立刻撤掉。
- 用两个测试账号走同一页面：一个全新，一个先建三条再全部删除。两屏若共用欢迎插画或共用回收站入口，来源就还没分开。改交付源里的条件帧，不要只在代码里加一个
isNewUser却继续渲染同一张图。