问题
LoginRequest 把 code 定义为必填，长度固定 6 位。也就是说这套认证没有「输入密码即可登录」的路径，每一次密码登录都要求用户先收一封邮件。
这条路径还叠加了两重约束：验证码发送有 60 秒冷却，/auth/send-code 属于敏感接口，受 10 次每分钟每 IP 的限流。用户在换设备或清理浏览器数据之后重新登录，最快也要等一次邮件往返。
同时 /auth/login-by-code 提供免密登录，无账号时自动注册。结果是免密路径比密码路径更快，密码的存在反而增加了摩擦而没有换来额外的便利。
安全上要求两个因素是成立的考虑，这里要确定的是这个强度是否与产品定位匹配，以及是否有更合适的触发条件。
目标
确定登录摩擦的产品口径，作为前端登录界面设计的依据。
待定的几种口径
- 密码登录不再要求验证码，验证码只用于注册、免密登录与重设密码。
- 保留验证码，但只在新设备、新 IP 或距上次登录超过一定时间时触发。
- 维持现状，并在登录界面明确告知用户每次登录都需要邮箱验证码。
范围
本 issue 只确定口径，不包含实现。结论确定后另开实现 issue。
需要的结论
- 采用哪一种口径。
- 若采用第二种，触发条件由谁判定、依据哪些信号。
- 前端登录界面是否需要为「等待邮件」这一步准备独立的状态与文案。
问题
LoginRequest把code定义为必填，长度固定 6 位。也就是说这套认证没有「输入密码即可登录」的路径，每一次密码登录都要求用户先收一封邮件。这条路径还叠加了两重约束：验证码发送有 60 秒冷却，
/auth/send-code属于敏感接口，受 10 次每分钟每 IP 的限流。用户在换设备或清理浏览器数据之后重新登录，最快也要等一次邮件往返。同时
/auth/login-by-code提供免密登录，无账号时自动注册。结果是免密路径比密码路径更快，密码的存在反而增加了摩擦而没有换来额外的便利。安全上要求两个因素是成立的考虑，这里要确定的是这个强度是否与产品定位匹配，以及是否有更合适的触发条件。
目标
确定登录摩擦的产品口径，作为前端登录界面设计的依据。
待定的几种口径
范围
本 issue 只确定口径，不包含实现。结论确定后另开实现 issue。
需要的结论