把“图标+文字”按钮压成纯图标后，状态怎么接管

工具栏横向空间不够时，最省事的做法是把“图标 + 文字”的按钮压成纯图标方块。难点不在换图，而在换完之后，原来由文字承担的“现在是什么状态”必须有人接手。下面是一套跑通的改法：按钮从 26×高 变成 26×26，状态全部交给图标表达。

什么情况下会撞上它

典型场景是编辑器或对话界面里挂了一个发布按钮，左侧一个上传箭头，右侧写着“发博客”。工具栏里并排放了好几个控件，横向空间被一点点吃掉，最后出现挤压或换行。

去掉文字后问题立刻出现：用户点下去，按钮没有任何变化，不知道是在发送、已经成功，还是失败了。省下的空间换来了不确定性。真正要改的不是“删文字”，而是“把文字承载的信息迁移到图标上”。

为什么状态必须由图标接管

文字按钮天然带状态：文案可以从“发博客”变成“发布中”，再变成“已发布”。纯图标没有这个余地，同一个位置只能画一个图形。

解决办法是让同一个按钮在不同阶段渲染不同的图形。这样按钮尺寸恒定，不会因为文字长短抖动，也不会因为状态切换导致布局重排。

四个状态覆盖一次发布的完整生命周期：

“跟随文字颜色”值得单独说：图标不要写死颜色，用 currentColor 之类的继承方式，浅色主题、深色主题、禁用态都能自动适配。

“成功”这一格容易被做成纯提示。更好的做法是让它可点，点开就是刚发出去的那篇文章——用户此刻最想做的事往往就是去看一眼结果。

“失败”这一格必须带原因。红色感叹号只告诉用户“出事了”，悬停或点击才给出具体信息，比如接口返回的错误、必填素材缺失。没有原因的失败提示，用户只能反复重试。

怎么做

第一步，准备图标资源。用官方 logo 的矢量路径，不要自己描一个近似的 W。路径写进前端 bundle，作为静态资源随插件一起加载。

第二步，把按钮的 DOM 结构从“图标 + 文本节点”改成单个容器，容器内根据状态渲染对应图形。尺寸固定成正方形，例如 26×26，避免不同图标视觉重量不一致导致按钮忽大忽小。

第三步，状态机只保留四个取值，不要引入中间态。发布请求发出时切到“发布中”，请求返回后根据结果切到“成功”或“失败”，用户重试时回到“发布中”。

第四步，两处入口同步改。同一个发布能力如果同时出现在回答下方的动作行和输入框左下角的工具行，两处都要换成新按钮，否则用户会在两个位置看到两种交互。

第五步，功能语义不要顺手改掉。Shift+点击仍然是“只试写不发布”，这是原有的调试入口，换图标时容易漏掉。

怎么确认改成了

最直接的验证是看宿主实际加载的 bundle 版本。前端资源通常带一个版本号或构建标识，确认它指向包含新 logo 路径的那一版，而不是浏览器缓存里的旧文件。

如果开发环境带热更新（HMR），插件一般会自动替换，不需要手动刷新页面。但热更新有概率错过那一帧，表现为“代码改了、界面没变”。这时刷新一次即可。

界面侧的自检清单：按钮是正方形；默认态显示 logo；点一下能看到转圈；成功后变成对勾且可点开文章；故意制造一次失败（例如断开接口），确认出现红色感叹号并且悬停能看到原因。

边界和代价

纯图标按钮牺牲的是可发现性。第一次使用的用户看到一圆一方两个图标，未必知道哪个是发布。缓解办法是加 title 或 aria-label，悬停给出文字说明，同时保证读屏软件能念出来。

四个状态之外不要再加第五个。状态越多，用户越难从图形反推当前处境，最后还是要靠文字解释。

图标尺寸压到 26×26 之后，点击热区会变小。如果工具栏本身密度高，建议用内边距把可点区域撑到 32 像素左右，视觉尺寸不变，手感不至于变差。