订单摘要应使用语义化的标签而非套娃，以确保屏幕阅读器识别键值对、打印样式正确；金额与日期须服务端渲染，避免js格式化导致的时区和本地化问题；只读状态必须用readonly/disabled属性而非仅css视觉禁用。
订单摘要用 <dl></dl> 而不是 <div> 套娃
<p>语义错误是这类页面最隐蔽的坑：用一堆 <code><div> 拼价格、地址、商品列表，会导致屏幕阅读器无法识别“项目名-值”关系，打印样式也容易错乱。浏览器原生对 <code><dl></dl> 的支持稳定，且能自然表达“订单号：ORD-2024-7890”这种键值对。
-
<dt></dt> 放字段名（如“收货地址”），<dd></dd> 放对应值，一对多时可多个 <dd></dd>
- 避免嵌套
<table> —— 表格用于二维数据，订单摘要本质是单维结构化信息
<li>如果含金额，用 <code><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>
<li>JavaScript 不应主动移除 <code>readonly 或监听 input 事件——确认页不该有“编辑入口”，除非明确跳转到编辑页
价格和日期必须服务端渲染，不能 JS 拼接
客户端用 new Date().toLocaleString() 或 Intl.NumberFormat 格式化，看似方便，但会因用户本地时区、语言设置导致金额显示不一致（比如 ¥1,234.50 在某些系统里变成 1.234,50），甚至被篡改。
html-to-pptx-converter
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
下载
- 金额统一由后端输出为带千分位、固定两位小数的字符串，如
"¥1,234.50"，前端直接插入 <dd></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></dl> 外层）设 max-width: 100% + overflow-x: hidden，防横向滚动条意外出现
- 价格数字字号在移动端至少
1.2rem，避免用户眯眼核对；<dt></dt> 和 <dd></dd> 建议用 flex 布局替代 float，兼容性好且不易塌陷
最容易被忽略的是「只读」的边界：用户截图、复制、打印都应得到与屏幕上完全一致的内容，这意味着所有关键字段必须是真实 DOM 文本，而不是 canvas 渲染、伪元素插入或 JS 动态 innerHTML —— 后者在无 JS 环境或打印预览里直接消失。
<dt></dt> 放字段名（如“收货地址”），<dd></dd> 放对应值，一对多时可多个 <dd></dd>
<table> —— 表格用于二维数据，订单摘要本质是单维结构化信息
<li>如果含金额，用 <code><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> <li>JavaScript 不应主动移除 <code>readonly或监听input事件——确认页不该有“编辑入口”，除非明确跳转到编辑页 - 金额统一由后端输出为带千分位、固定两位小数的字符串，如
"¥1,234.50"，前端直接插入<dd></dd>，不重新 parse - 日期同理，用 ISO 8601 字符串（如
"2024-05-22T14:30:00+08:00"）配合后端模板渲染成本地格式，避免 JS 时区换算误差 - 若必须前端处理（如 SSR 不足），至少用
Intl.DateTimeFormat和Intl.NumberFormat显式指定locale和currency，而非依赖 navigator.language - 用
<meta name="viewport" content="width=device-width, initial-scale=1">是基础，但不够——需测试主流安卓/iOS 微信内置浏览器的实际screen.width - 关键容器（如
<dl></dl>外层）设max-width: 100%+overflow-x: hidden，防横向滚动条意外出现 - 价格数字字号在移动端至少
1.2rem，避免用户眯眼核对；<dt></dt>和<dd></dd>建议用 flex 布局替代 float，兼容性好且不易塌陷
价格和日期必须服务端渲染，不能 JS 拼接
客户端用 new Date().toLocaleString() 或 Intl.NumberFormat 格式化，看似方便，但会因用户本地时区、语言设置导致金额显示不一致（比如 ¥1,234.50 在某些系统里变成 1.234,50），甚至被篡改。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
响应式断点要匹配真实设备，不是拍脑袋设 768px
订单确认页在手机上常被横向滑动、文字溢出、按钮被遮挡，问题往往出在媒体查询断点和容器宽度没对齐真实 viewport。
最容易被忽略的是「只读」的边界：用户截图、复制、打印都应得到与屏幕上完全一致的内容，这意味着所有关键字段必须是真实 DOM 文本，而不是 canvas 渲染、伪元素插入或 JS 动态 innerHTML —— 后者在无 JS 环境或打印预览里直接消失。
