value属性与显示文本分离是HTML标准做法，提交和获取表单值时使用value，用户看到的是标签内文本，前后端需一致处理该分离。
当 <select> 中的 <option> 的 value 属性与显示文本不一致时，浏览器默认行为是：提交或获取表单值时使用 value，而用户看到的是标签内的文本内容。这是正常且推荐的设计方式，并非错误，关键在于前后端对这个“分离”保持一致理解与处理。
value 与文本分离是标准做法
HTML 规范明确允许并鼓励这种分离。例如：
<option value="shanghai">上海市</option>
<option value="beijing">北京市</option>
这样设计的好处包括：
立即学习“前端免费学习笔记（深入）”；
- 避免中文、空格、特殊符号影响后端处理（如 URL 参数、数据库字段、API 校验）
- 支持多语言界面：同一
value可对应不同语言的显示文本 - 便于程序化操作：JS 获取
select.value得到稳定标识符，而非依赖易变的显示文字
JavaScript 获取选中项时注意区分
不要用 option.text 或 option.innerHTML 来代表选项身份，应优先使用 select.value 或 selectedOptions[0].value：
const sel = document.querySelector('select');
console.log(sel.value); // ✅ 推荐：返回 "shanghai"
console.log(sel.selectedOptions[0].text); // ❌ 避免：返回 "上海市"，不可靠
若确需根据 value 查找对应文本（比如日志展示），可保留映射关系或通过 DOM 查询：
const text = Array.from(sel.options)
.find(opt => opt.value === sel.value)?.text || '';
后端接收时只信任 value，不解析文本
服务端必须依据 value 做业务判断，绝不能尝试从提交的文本中提取或匹配。例如：
- 表单 POST 提交时，字段值是
city=shanghai，不是city=上海市 - API 接口文档应明确定义
value的取值范围（如枚举："shanghai", "beijing", "guangzhou"） - 若前端误传了文本（如用 JS 手动设置
select.value = '上海市'），后端应拒绝并报错，而不是做模糊匹配
调试与排查常见误区
遇到“选了却没生效”或“值对不上”，检查以下几点：
- 确认
<option>确实设置了value属性（未设置时，value默认等于文本内容，容易掩盖问题） - 检查是否有 JS 动态修改了
value或覆盖了innerHTML，导致语义错乱 - 审查网络请求的 payload，确认实际提交的是哪个字段和值（Chrome DevTools → Network → Form Data）
- 服务端打印原始参数，验证是否收到预期的
value字符串
