文章摘要
文章批评现代网页设计中自行开发加密方案的做法，类比密码学领域"不要自创加密算法"的原则，强调应使用经过验证的标准加密工具而非未经审查的自研方案，以保护用户数据安全。作者指出当前行业已普遍采用这一做法，但20年前仍常见有缺陷的自研加密实现。
文章总结
文章改写：《请勿自行造轮子》
作者：Susam Pal
发布日期：2026年5月23日
本文旨在探讨现代网页设计中的一些常见问题。开篇之前，我想先引用密码学领域的一条原则：不要自行实现加密算法（Don't roll your own crypto）。这条原则并非禁止开发者编写加密代码，而是强调在保护用户敏感数据时，应使用经过广泛审查的成熟方案，而非未经测试的私有实现。
如今，行业已普遍遵循这一原则。但在二十年前，我曾目睹许多漏洞百出的自定义RC4算法，如初始化向量不当、密钥流可预测等问题，导致用户数据暴露。如今，电商和银行网站已不再使用自研加密方案，部分领域（如支付、医疗）甚至强制要求采用标准化加密，否则可能面临重罚。
虽然网页设计与密码学无关，但某些自行实现的网页功能同样会破坏用户体验。以下是我认为不应自行造轮子的典型场景：
- 禁止自定义页面滚动
- 禁止自定义链接跳转
- 禁止自定义文本选择
- 禁止自定义右键菜单
- 禁止自定义复制粘贴
- 禁止自定义密码输入框
- 禁止自定义日期选择器
当然，某些特殊场景确实需要定制化开发。但本文聚焦于那些本应由浏览器原生支持、却被过度改造的功能——它们往往适得其反。
用户痛点案例
自定义滚动
强行覆盖浏览器默认滚动行为会导致响应迟缓、键盘支持失效，迫使用户适应陌生的交互逻辑。自定义链接跳转
GitHub是典型反面教材：点击链接时会触发复杂的JavaScript流程，反而比原生跳转更慢。通过开发者工具监听点击事件即可验证这一点。自定义密码框
浏览器原生密码框支持密码管理、自动填充、安全警告等功能。若替换为自行实现的伪密码框，可能破坏这些特性，甚至意外暴露明文密码。自定义日期选择器
各网站的实现千奇百怪：有的需切换年/月视图，有的要点击几十次选择年份，有的禁止手动输入。用户更希望统一使用浏览器原生日期控件，而非学习不同网站的独有设计。
呼吁与建议
- 保持表单控件原生性：自定义控件往往引入新问题。
- 减少界面频繁改版：老年人等群体难以适应频繁变化的UI，这无异于强迫他们反复学习同一工具。试想如果Linux命令或洗衣机按键每月重组，会多么令人崩溃。
本文仅代表一名普通用户的吐槽，而非专业设计指南。但请开发者们记住：尊重用户习惯，慎造不必要的轮子。
（注：原文中的GitHub调试截图及部分技术细节已简化，核心观点保留完整。）
评论总结
以下是评论内容的总结，平衡呈现不同观点并保留关键引用：
支持使用浏览器原生功能 1. 认为浏览器原生组件足够好，自定义反而破坏体验： - "浏览器一直在增加原生支持，你真的需要特殊处理吗？" (giancarlostoro) - "完全同意。工程师为什么要改造滚动条/密码框？结果只会让网站体验变差" (chihuahua)
- 原生组件更稳定且可访问：
- "作为屏幕阅读用户，自定义控件很少遵循ARIA规范，导致网络可访问性下降" (ethin)
- "图片查看器就该用原生img标签，Twitter/Google的自定义实现总有多点触控问题" (bschwindHN)
支持有限度的自定义 1. 部分场景需要增强原生功能： - "大多数日期选择器比浏览器默认更好，只是遗憾不能更好定制样式" (singiamtel) - "单页应用的路由导航体验比传统页面跳转更好" (rozumem)
- 依赖第三方库的问题：
- "npm供应链攻击时代，有时自己实现反而更安全" (awongh)
- "别人的代码越来越臃肿，依赖项越来越多，带来间接的维护问题" (kazinator)
强烈反对自定义核心交互 1. 坚决反对修改基础交互： - "永远没有理由改造页面滚动，这纯粹是糟糕的设计" (bigstrat2003) - "浏览器根本不该让网页获取滚动/选择/复制粘贴等用户操作权限" (NooneAtAll3)
- 批评商业动机：
- "不自定义返回按钮行为就少了几次展示广告的机会" (zephen)
- "Google通过让浏览器复杂化来建立竞争壁垒" (lysace)
中间立场 - "应该视情况而定，但我反对为了一个按钮动画加载500KB" (ChrisMarshallNY) - "UX需要标准化，但达成共识很难，即使浏览器实现了标准组件也难以推广" (wxw)
关键矛盾点在于：用户体验一致性 vs 特殊需求实现，商业利益 vs 用户权益，开发效率 vs 系统安全性。原生派强调可预测性和可访问性，自定义派则关注功能增强和避免第三方依赖风险。