时区下拉菜单value必须用iana标识符（如"asia/shanghai"），不可用gmt偏移或中文名；显示文本可本地化；应动态生成选项并严格校验输入。
HTML 下拉菜单怎么写时区选项才不翻车
直接用 <select></select> + <option></option> 写时区下拉菜单没问题，但硬编码时区名（比如写 "GMT+8" 或 "China Standard Time"）会立刻导致后端解析失败、前端时区计算错乱、用户选了却不知道对应哪里——根本原因在于：浏览器和服务器认的不是人话，是 IANA 时区标识符（如 "Asia/Shanghai"）。
为什么不能用 GMT 偏移或中文名当 value
GMT 偏移（如 "+08:00"）不是唯一标识：同一个偏移可能对应多个时区（Asia/Shanghai 和 Asia/Ulaanbaatar 夏令时都可能是 +08:00），且不随夏令时自动切换；中文名（如 "北京时间"）无法被 Intl.DateTimeFormat 或 Python 的 zoneinfo 识别，后端拿到就只能报错或默认 UTC。
-
value必须是标准 IANA 时区名（全小写、斜杠分隔），例如"America/New_York"、"Europe/London"、"Asia/Tokyo" - 显示文本（
<option></option>内容）可以是本地化友好名称，比如北京时间、纽约时间，但绝不能和value混为一谈 - 别漏掉
"UTC"—— 它是合法时区名，且常被系统用作基准
怎么生成靠谱的时区 option 列表
手写几十个时区容易漏、易拼错、难维护。推荐用 JavaScript 动态生成（服务端渲染同理，用对应语言的时区库）：
const tzOptions = Intl.supportedValuesOf('timeZone')
.filter(tz => !tz.startsWith('Etc/') && !tz.includes('ROC') && !tz.includes('PRC'))
.map(tz => {
const formatter = new Intl.DateTimeFormat('zh-CN', { timeZone: tz, hour12: false, hour: '2-digit', minute: '2-digit' });
const now = formatter.format(new Date());
return `<option value="${tz}">${tz} (当前 ${now})</option>`;
})
.join('');
关键点：
- 用
Intl.supportedValuesOf('timeZone')获取浏览器支持的完整列表，比查维基靠谱 - 过滤掉
Etc/GMT*类（它们的偏移是反的，Etc/GMT+8实际是 UTC−08:00）、ROC/PRC（已废弃） - 别在 HTML 里硬塞几百个
<option></option>—— 页面体积大、加载慢，且移动端下拉卡顿
后端收到时区 value 后怎么安全处理
用户提交的 value 是字符串，必须校验后再进业务逻辑，否则可能被注入非法时区名（如 "../../../etc/passwd" 虽然不会生效，但说明没做白名单）：
- 校验必须基于 IANA 官方时区数据库（Python 用
zoneinfo.available_timezones()，Node.js 用moment-timezone的moment.tz.names()） - 拒绝所有含
/、..、控制字符的输入，只放行已知有效时区名 - 注意：
"UTC"和"Etc/UTC"都合法，但语义等价，建议统一转成"UTC"存储
时区不是标签，是运行时上下文。选错一个 value，后面所有时间计算、日志打点、定时任务都会悄悄偏移——最麻烦的是它不报错，只“看起来差不多”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
