订单摘要应使用语义化的<dl>标签而非<div>套娃，以确保屏幕阅读器识别键值对、打印样式正确；金额与日期须服务端渲染，避免JS格式化导致的时区和本地化问题；只读状态必须用readonly/disabled属性而非仅CSS视觉禁用。
订单摘要用 <dl> 而不是 <div> 套娃
语义错误是这类页面最隐蔽的坑：用一堆 <div> 拼价格、地址、商品列表，会导致屏幕阅读器无法识别“项目名-值”关系，打印样式也容易错乱。浏览器原生对 <dl> 的支持稳定，且能自然表达“订单号：ORD-2024-7890”这种键值对。
-
<dt>放字段名（如“收货地址”），<dd>放对应值，一对多时可多个<dd> - 避免嵌套
<table>—— 表格用于二维数据，订单摘要本质是单维结构化信息 - 如果含金额，用
<span class="price"></span>包裹数字，方便 CSS 精确控制货币符号位置和小数位对齐
只读状态必须靠 HTML 属性，不能只靠 CSS
视觉上灰掉输入框、禁用按钮不等于真正只读；用户仍可能用键盘 Tab 进入、用 DevTools 改 value、或绕过前端校验提交脏数据。
- 所有表单控件加
readonly（文本类）或disabled（按钮/选择器），二者行为不同：disabled字段不会随表单提交，readonly会 - 隐藏的原始数据（如订单 ID、用户 ID）用
<input type="hidden" name="order_id" value="...">，别用display: none的<div> - JavaScript 不应主动移除
readonly或监听input事件——确认页不该有“编辑入口”，除非明确跳转到编辑页
价格和日期必须服务端渲染，不能 JS 拼接
客户端用 new Date().toLocaleString() 或 Intl.NumberFormat 格式化，看似方便，但会因用户本地时区、语言设置导致金额显示不一致（比如 ¥1,234.50 在某些系统里变成 1.234,50），甚至被篡改。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 金额统一由后端输出为带千分位、固定两位小数的字符串，如
"¥1,234.50"，前端直接插入<dd>，不重新 parse - 日期同理，用 ISO 8601 字符串（如
"2024-05-22T14:30:00+08:00"）配合后端模板渲染成本地格式，避免 JS 时区换算误差 - 若必须前端处理（如 SSR 不足），至少用
Intl.DateTimeFormat和Intl.NumberFormat显式指定locale和currency，而非依赖 navigator.language
响应式断点要匹配真实设备，不是拍脑袋设 768px
订单确认页在手机上常被横向滑动、文字溢出、按钮被遮挡，问题往往出在媒体查询断点和容器宽度没对齐真实 viewport。
立即学习“前端免费学习笔记（深入）”；
- 用
<meta name="viewport" content="width=device-width, initial-scale=1">是基础，但不够——需测试主流安卓/iOS 微信内置浏览器的实际screen.width - 关键容器（如
<dl>外层）设max-width: 100%+overflow-x: hidden，防横向滚动条意外出现 - 价格数字字号在移动端至少
1.2rem，避免用户眯眼核对；<dt>和<dd>建议用 flex 布局替代 float，兼容性好且不易塌陷
最容易被忽略的是「只读」的边界：用户截图、复制、打印都应得到与屏幕上完全一致的内容，这意味着所有关键字段必须是真实 DOM 文本，而不是 canvas 渲染、伪元素插入或 JS 动态 innerHTML —— 后者在无 JS 环境或打印预览里直接消失。
