菏泽企业的询价表里，展开说明和提交需求看起来都可以做成按钮，但二者执行的动作不同。若点击一个辅助按钮就出现验证提示甚至发出请求，应先核对元素的type及相关脚本。文案写着展开，并不能改变浏览器对按钮类型的处理。
从一段自拟HTML识别动作
<form id="demo-buttons">
<label>示意对象 <input name="model" value="DEMO-A"></label>
<button type="button" id="show-help">展开说明</button>
<button type="submit" id="send-demo">提交演示</button>
</form>MDN说明，与表单关联的button若未指定有效type，默认行为是submit；type=button没有该默认提交动作，可以再由脚本实现局部操作。样例特意明确两种类型，但真实项目仍需核对事件监听和请求，不能以属性正确推断所有程序正确。
把所有按钮按意图分类
| 按钮任务 | 候选类型或实现 | 实际要复测 |
|---|---|---|
| 展开一段说明 | button加明确交互逻辑 | 不误触发需求提交 |
| 提交需求 | submit及对应处理 | 验证、请求、保存与反馈 |
| 返回或跳转资料 | 按真实导航任务选元素 | 目标和原任务状态 |
| 重置内容 | 只有明确需要才采用 | 是否恢复默认值及是否告知用户 |
误提交排查，不只检查视觉组件
1意图写清每个按钮执行什么。
2元素检查类型与所属表单。
3事件观察实际监听和请求。
4反馈确保只报告真正完成的动作。
- 用示意资料在隔离环境点击辅助按钮。
- 记录是否触发表单submit事件及验证。
- 再单独核对真正提交按钮。
- 检查键盘操作与手机布局下是否还是同一个元素。
只写onclick能解决吗？
要检查具体代码与默认行为，不能仅因有监听就假定不会提交。
默认提交一定已经生成询盘吗？
不一定，可能被验证、事件或接口拒绝。应看真实请求和接收结果，不制造虚假业务记录。
交接时列出按钮意图与实际行为，比只交一张页面截图更便于维护。辅助入口和提交入口应分别验收，避免一个局部设计动作影响整条需求接收路径。