在线工具页面应以输入-处理-输出三步链路清晰为核心，用语义化main+section结构、flex响应式布局、pre+code输出及DOM属性驱动状态，确保可访问性与确定性。
在线工具页面不是“堆功能”，而是让输入、处理、输出三步链路清晰、低干扰、可预期。核心是控制视觉动线，而不是炫技布局。
用 main + section 搭主结构，别用 div 套娃
工具页本质是单任务导向：用户来就为做一件事（比如 Base64 编码）。语义化标签直接锚定意图，比一堆 div class="wrapper-inner-box"> 更可靠。
-
main包整个工具逻辑区，屏幕阅读器和 SEO 都认它为“主要内容” - 每个功能区块用
section，加aria-labelledby关联标题，比如<section aria-labelledby="base64-title"><h2 id="base64-title">Base64 编码</h2>...</section> - 避免嵌套超过 3 层：输入框 → 按钮 → 结果区，这三层足够；再套一层
div只会增加 CSS 选择器负担和调试难度 - 不用
header包工具标题——它属于页面级导航，工具标题用h1或h2即可，否则语义错位
display: flex 控制输入/按钮/输出的横向流，flex-direction: column 保移动端堆叠
工具页最常见错误：在桌面端强行三栏（输入栏+操作栏+结果栏），结果小屏一塌糊涂。Flex 的优势在于用同一套 HTML 应对两种流向。
- 父容器设
display: flex; flex-direction: column;，子元素默认垂直堆叠 - 媒体查询里切到桌面端：
@media (min-width: 768px) { .tool-container { flex-direction: row; } } - 输入区设
flex: 1;，按钮固定高宽（如flex: 0 0 120px;），结果区也flex: 1;，三者自动等高并填满容器 - 关键补丁：
min-width: 0;加在输入textarea和结果pre上——否则长文本或 URL 会撑破容器，Flex 默认不截断
结果区用 pre + code，别用 div + white-space: pre-wrap
工具输出常含换行、缩进、特殊字符（比如 JSON、正则、HTML 片段）。用通用容器模拟代码块，等于自己造轮子还漏细节。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 直接用
<pre><code class="json">{...}</code></pre>，语义准、样式稳、无障碍友好 - CSS 只需一行：
pre { overflow-x: auto; max-height: 300px; }，滚动可控，不会溢出 - 如果要高亮，用
highlight.js或Prism.js，它们只认code标签，对div不生效 - 别给
pre设width: 100%—— 它默认是 inline-block，宽度由内容撑开；加了 width 反而破坏预格式化行为
按钮状态和错误提示必须绑定 DOM 属性，不能只靠 class 切换
工具页高频交互：点按钮 → 等待 → 出结果或报错。仅用 .loading / .error class 控制样式，容易导致状态残留或竞态问题。
- 按钮用
disabled属性禁用，同时加aria-busy="true"，屏幕阅读器能感知“正在处理” - 错误信息放
span里，用aria-live="polite"，变化时自动朗读，不用手动 focus - 成功结果出现后，清空错误提示的
textContent，而不是display: none—— 否则下次出错可能不显示（DOM 还在但被隐藏） - 别用
setTimeout模拟 loading 状态 —— 真实工具调用可能是微秒级，延时反而造成“卡顿”错觉
真正难的不是写几行 grid-template-areas，而是让每次点击都有确定反馈、每次粘贴都立刻响应、每次错误都指向具体字段。布局只是容器，别让它抢了工具本身该有的确定性。
