未写value时表单提交的是textContent，如<option>苹果</option>等价于<option value="苹果">苹果</option>，但易因空格、换行、编码等问题导致后端解析失败，故应始终显式声明value。
option 没写 value 时，表单提交的是 text 内容
浏览器会把 <option> 标签内的纯文本（即 textContent）当作默认的 value 提交。比如：<option>苹果</option> 等价于 <option value="苹果">苹果</option>。
这看似省事，但实际埋了几个坑：
- 文本含空格、换行、全角符号或 HTML 实体（如
- 中文、emoji 或特殊标点在某些编码环境下容易乱码，尤其用
GET提交时 URL 编码不一致 - 如果文本是“请选择”“-- 请选择 --”这类提示语，它会被当成有效值提交，而不是空值
- React/Vue 等框架里，若
value和绑定值类型不一致（比如后端期望数字"1"，但你写了<option>1</option>），容易触发受控组件警告或卡死
value 缺省 + text 是数字，能当 ID 用吗
不能直接依赖。虽然 <option>42</option> 提交的是字符串 "42"，但以下情况会出问题：
- 后端期望整型字段，收到字符串
"42"可能被强转失败（如 Go 的json.Unmarshal默认不自动转类型） - text 是
"007"或"1e2"，缺省 value 就是原样字符串，不是数字7或100 - 多个选项 text 相同但语义不同（如两个
<option>待审核</option>），无法区分，必须靠显式value区分
没写 value 时，JS 读取 select.value 返回什么
返回的是该 <option> 的 value 属性值；如果属性不存在，就返回其 textContent —— 也就是和表单提交一致。
立即学习“前端免费学习笔记（深入）”；
但注意这个逻辑只在 select 已渲染、且有选中项时生效。常见错误包括：
- 用
getAttribute('value')读取未选中项：返回null，不是当前选中值 - 动态插入
<option>后没调用select.value = ...或select.selectedIndex = ...，导致select.value仍为空字符串 - 在
DOMContentLoaded前读取，DOM 还没挂载，select可能为null
为什么推荐始终显式写 value
显式声明 value 是唯一能解耦“显示内容”和“传输语义”的方式：
-
<option value="status_pending">待处理</option>—— 后端按枚举名处理，前端可自由改文案不影响接口 -
<option value="1">管理员</option>—— 数字 ID 安全、无歧义、兼容性好 - 避免因空格缩进、换行符等不可见字符污染 value（比如
<option>\n 管理员\n</option>的 value 会是"\n 管理员\n"） - 服务端校验、日志追踪、A/B 测试分流都依赖稳定、可预测的 value 字符串
最麻烦的不是写 value，而是某天发现三个地方的 <option>已启用</option> 其实对应三种状态，但都缺 value，只能靠文本硬匹配——这种债，越拖越难还。
