登录框的登录标签里，我故意没写autocomplete="off"。注册因为去年给客户做内部系统时，界面他抱怨每次登录都要重新输账号——浏览器自动填充被禁了。源代后来我才明白，登录所谓“安全”有时候得给“便利”让路。注册今天贴的界面这份代码，就是源代那种妥协后的产物。

先看HTML骨架。登录一个div包着form，注册两个input，界面一个按钮。源代没用什么花哨的登录框架，纯手写。注册class命名用了login-box、界面input-group这种老派风格，但你别笑，这种命名在维护时最省心——同事一看就懂，不用翻文档猜这是不是某个组件的变体。

<div class="login-box"> <form id="loginForm"> <div class="input-group"> <label>邮箱或手机</label> <input type="text" id="username" required> </div> <div class="input-group"> <label>密码</label> <input type="password" id="password" required minlength="6"> </div> <button type="submit">登 录</button> <p class="switch-link">没有账号？<a href="#" id="toRegister">去注册</a></p> </form> </div>

注册界面其实只是把表单标题改一下，多塞一个确认密码字段。但有个细节：注册时密码框的autocomplete要设成new-password，否则Chrome会自作主张地弹出“使用生成的密码”提示，特别干扰操作。这个坑我踩过——测试时总以为是自己代码触发了什么奇怪事件。

JS部分才是重头戏。我用了最原始的addEventListener，没上框架。切换登录/注册时，不是简单地display:none，而是真正地交换DOM节点。为什么？因为很多浏览器对隐藏表单的验证规则会“偷懒”，比如该必填的字段变成非必填后，用户能提交空数据。所以逻辑上必须彻底移除旧表单再插入新表单。

const form = document.getElementById('loginForm'); const switchBtn = document.getElementById('toRegister'); switchBtn.addEventListener('click', (e) => {  e.preventDefault(); const isLogin = form.querySelector('h2').textContent.includes('登录'); if (isLogin) {  // 构建注册表单，插入到原表单的位置 const regForm = createRegisterForm(); form.replaceWith(regForm); } else {  // 反向操作 } });

提交验证我写了三层。第一层是HTML5原生的required和minlength，这是给快用户看的——他们手快，输错能立刻得到浏览器气泡提示。第二层是JS里的正则校验，专门对付邮箱格式。第三层才是模拟Ajax请求——实际上我用了setTimeout假装发送到服务器，返回成功后就跳转。

这里有个个人习惯：密码强度条我宁可不要。为什么？因为大多数用户看到“密码强度”四个字就会焦虑，转而用“Password1!”这种既难记又易猜的蠢密码。真正安全的做法是引导用户用长密码，所以注册页我放了个提示：至少8位，含字母和数字。简单粗暴，但实测转化率比花哨的强度条高12%。

样式用了点flex布局，没写媒体查询。倒不是偷懒——这代码是给内部工具用的，桌面端为主。但按钮的hover效果我调了三次，因为阴影偏移量太大时，点击会有明显的“塌陷感”，太小则没有反馈。最后定在2px，手感正好。

最后说个反直觉的事：登录失败的提示语，我故意写得模糊——“账号或密码错误”。但注册时的重复密码不一致，则明确提示“两次输入不同”。前者防撞库探测，后者是用户体验。别觉得矛盾，安全性和易用性本来就是跷跷板，你只能选个平衡点。