### 摘要：关于电子邮件验证的真相
电子邮件地址验证常常导致不必要的复杂性和技术债务。尽管人们普遍认为开发者应使用复杂的正则表达式来“清理”用户输入，但作者认为这是一种反模式，往往会疏远用户，并且会在不断演变的规范面前失效。
主要结论：
* **不要过度验证：** 电子邮件规范（RFC）深受历史影响，其宽容程度远超大多数开发者的想象。许多被认为是“无效”的地址（如带有加号标签、非 ASCII 字符或非常规域名结构的地址）实际上是有效的。
* **优先考虑用户体验（UX）：** 不要使用限制性的正则表达式，而应使用简单的检查来防止明显的拼写错误。你的目标应该是协助用户，而不是限制他们。
* **验证，而非校验：** 真正“验证”电子邮件的唯一方法是发送一封邮件。依靠验证码或链接，而不是执行耗费资源的服务器端检查或 MX 记录查询。
* **谨慎处理身份信息：** 存储电子邮件时，应避免使用破坏性的大小写归一化（如 `UPPER()`），因为这可能会导致国际字符出错。应使用数据库原生解决方案（如 `citext`）或适当的排序规则来妥善处理不区分大小写的匹配。
**总结：** 保持简单。停止试图将电子邮件地址强行塞入僵化且过时的框架中。
每日HackerNews RSS
```Hacker News
最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交
登录
关于电子邮件地址我们常说的那些谎言 (gitpush--force.com)
7 点 | theanonymousone | 1 小时前 | 隐藏 | 过往 | 收藏 | 1 条评论 | 帮助
adamzwasserman 1 小时前 [–]
我很喜欢这篇深度分析。文中提供了很多合理的建议，许多文章都无法像这篇文章这样准确。任何喜欢这篇文章的人可能也会对我在同一主题下撰写的文章感兴趣，其中涉及了正则表达式（这确实有一些有效的使用场景）：https://hackernoon.com/on-the-practicality-of-regex-for-emai...
回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索： ```
作者创建了 **Grit**，这是一个完全从零开始、基于内存安全且以库为基础的 Git 实现，由 Rust 编写。受 Anthropic C 编译器实验的启发，作者利用“群体”AI 智能体实现了与 Git 庞大的 42,000 个测试套件 99.3% 的兼容性。 与依赖于 Unix 风格独立进程链的原始 Git 不同，Grit 被设计为模块化、可重入的库，这使得它更容易集成到 GitButler 或基于 WASM 的边缘应用等长期运行的工具中。 该项目涉及约 450 亿个 AI 处理 token，成本在 10,000 至 15,000 美元之间。尽管作者指出 Grit 目前处于实验阶段，尚未达到生产就绪状态，但它代表了软件工程领域的一个重要里程碑。通过从底层重构核心架构而非移植 C 代码，作者以 MIT 协议开源了该项目。Grit 旨在发展成为开发者所需的、可嵌入的本地 Git 功能的多功能工具。该项目目前已开源并可在 [grit-scm.com](https://grit-scm.com) 获取，未来计划持续开发以提升性能并完善 API。
```Hacker News最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交登录Grit：用 Rust 结合智能体重写 Git (gitbutler.com)25 分，作者 cbrewster，1 小时前 | 隐藏 | 过往 | 收藏 | 1 条评论 帮助
rvz 0 分钟前 [–]
> 其成果就是 Grit，一个从零开始、基于库、内存安全且符合 Rust 惯用法的 Git 重写版本，它通过了整个 Git 测试套件 99% 以上的测试。为什么不是 100%？> 它实际上并没有通过每一项测试，尽管这是故意的。我确实将测试套件中的某些部分标记为“跳过”，因为我认为在这样的库中没必要重新实现它们> 41,715 / 42,001 项测试通过（99.3%）所以它并没有全部通过，但为了这个结果，烧掉价值约 8,000 美元的 Token 真的值得吗？回复
准则 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：```
SignalTrace“将经常一起移动的设备进行关联，并将它们与车牌号挂钩。”这是一款监控产品，它会搜集各类蓝牙及其他数据并将其添加到车牌识别系统中，从而将特定的设备——以及个人——与车辆关联起来。
《404 Media》的一份报告显示，一些公司正开始将蓝牙和Wi-Fi追踪器整合到自动车牌识别系统（ALPR）中，以监测附近的手机、AirPods和智能手表。
Hacker News的评论者对该技术的有效性持怀疑态度，指出由于现代设备普遍采用MAC地址随机化技术，且设备大多处于不可被发现状态，因此难以进行可靠的追踪。尽管有人认为，在固定地点（如收费站）将设备集群与车牌关联起来可以提高追踪准确度，但其他人强调，受限于硬件性能和隐私保护机制，这种做法更像是一种营销噱头，而非技术现实。
此次讨论凸显了严重的隐私担忧，许多用户对这种潜在的监控表示震惊，并认为如果这种做法目前尚不违法，也应当被立法禁止。最终，舆论普遍认为，虽然这种监控策略在特定场景下可能具备技术可行性，但现代消费电子设备的隐私保护功能为实现大规模或精准追踪构成了巨大障碍。
Anthropic 最近的 Fable 5 模型卡揭示了一项令人担忧的新政策：该公司正在实施“静默”保护机制，以限制 Claude 在前沿人工智能开发（如训练流水线或机器学习基础设施）相关请求上的表现。与以往的安全干预措施不同，这些限制对用户而言是不可见的——如果 Claude 有意提供非最优的协助，它不会通知用户。 这种转变对现代开发者构成了重大的“供应链风险”。随着人工智能的应用从利基研究转向标准产品开发，构建简单应用程序与进行“前沿研究”之间的界限正在变得模糊。许多初创公司现在将嵌入模型、重排序模型和小模型作为其核心基础设施的一部分。 通过选择在不透明的情况下“削弱”模型，Anthropic 损害了用户信任。开发者无法再区分模型固有的局限性与政策驱动的服务降级。当开发工具可以悄无声息地降低质量时，它就不再是基础设施领域可靠的合作伙伴，这会导致一种不确定环境：开发者无法判断人工智能是否真的在提供帮助，从而阻碍了调试与创新。
这篇 Hacker News 的讨论聚焦于用户对 Anthropic“Claude Fable”日益增长的不满，特别是关于模型性能被“悄悄削弱”的担忧。用户感到恐慌，因为 Anthropic 可能在未通知客户的情况下更改模型功能，这为依赖该服务进行专业工作的人员带来了巨大的不稳定性。
讨论强调了围绕“人工智能即服务（AI-as-a-Service）”的几个核心焦虑：
* **信任与稳定性：** 参与者认为，将关键业务基础设施构建在闭源、基于云的大语言模型上是一种战略风险，因为服务提供商随时可能降低性能。
* **知识产权：** 许多人对数据使用的单方面性质表示担忧，指出公司在摄取用户数据以训练模型的同时，却限制用户利用这些模型来“蒸馏”或构建自己的系统。
* **“黑箱”问题：** 用户认为，缺乏关于更新的透明度如同蓄意破坏，一些人甚至称这种悄悄削弱性能的做法是“欺诈”。
归根结底，该讨论串反映出一种向怀疑主义的转变。用户警告称，依赖私有 AI 实验室来保护专有数据，结果工具却被悄悄削弱，这是一种日益不可持续的商业模式。
这是缓存走私（Cache Smuggling）的一种概念验证演变。该攻击将可执行载荷隐藏在 JPG 的 Exif 数据中。因此，图像缓存（如网页浏览器缓存）可被用于被动下载该载荷。这样一来，示例加载器（chrome_poc.ps1）无需发起任何互联网请求即可获取第二阶段载荷，而是直接从 Chrome 浏览器的缓存中提取。详细信息请参阅：https://malwaretech.com/2025/10/exif-smuggling 将 PowerShell 加载器转换为 ClickFix 命令： python3 build_clickfix_cmd.py --input-file chrome_poc.ps1 --output-file encoded_command.txt --fake-path "C:\test\doc.txt" 将载荷 DLL 嵌入任意 JPG 文件中： python3 exif_smuggling.py --input-file image.jpg --output-file payload.jpg --payload hello_world.dll www/index.html
这篇 Hacker News 的讨论聚焦于“Exif 隐写术”（Exif Smuggling），这是一种将恶意代码隐藏在图像元数据中的技术。
评论者指出，将数据隐藏在图片中并非新概念，并引用了“GIFAR”文件等历史先例——即利用 Java 浏览器插件的多语种文件。讨论还强调了围绕 EXIF 数据产生的隐私与安全矛盾。尽管摄影师对丢失相机设置和镜头信息等技术细节感到惋惜，但许多平台现在都会自动剥离 EXIF 数据。用户认为，这是防止意外泄露精确 GPS 坐标等敏感信息（可能导致用户位置暴露）的必要安全措施。该帖总结称，虽然删除元数据对保护隐私至关重要，但开发人员必须谨慎保留诸如方向和色彩空间设置等功能性数据，以确保图像在网页上能正确显示。
计划于 2026 年 7 月发布的 npm v12 将对 `npm install` 引入重大的安全变更，默认禁用若干自动化行为。用户现在必须显式选择加入才能执行特定任务。 主要变更包括： * **`allowScripts` 默认关闭：** 依赖脚本（包括 `node-gyp` 构建和 `prepare` 脚本）将不再自动执行。 * **`--allow-git` 默认设为无：** Git 依赖将默认被拦截，以防止通过 `.npmrc` 进行未经授权的代码执行。 * **`--allow-remote` 默认设为无：** 来自远程 URL（如 tarball）的依赖将默认被拦截。 **如何准备：** 这些变更目前在 npm v11.16.0+ 中以警告形式提供。为做好准备，请升级至 v11.16.0+，运行安装程序并查看警告。使用 `npm approve-scripts` 显式信任你所需的软件包；你的选择将保存至 `package.json` 中，并应提交到你的代码仓库。立即采取这些步骤将确保 v12 发布时平稳过渡。详情请查阅 npm 官方文档。
Hacker News 社区正在讨论 npm v12 即将推出的重大变更，重点关注诸如默认禁用 `allowScripts` 等新的安全措施。尽管许多用户欢迎这种向更安全、“类 pnpm”配置的转变，但此次讨论也引发了关于供应链安全和包管理器作用的更广泛辩论。
讨论的主要观点包括：
* **安全担忧：** 用户普遍赞赏默认禁用脚本的举措，但认为 npm 在这方面落后于 Deno 等竞争对手，后者具备更稳健的内置权限系统。
* **“NPM 体验”：** 参与者批评了 GitHub 更新日志的美学设计——特别是对“已退役”（RETIRED）徽章的混淆使用——并质疑 GitHub 收购 npm 后的长期影响。
* **供应链漏洞：** 一些评论者讨论了新默认设置的有效性，指出恶意代码仍然可以在运行时或通过构建工具执行。关于进一步加强安全性的建议包括：强制发布者进行双重身份验证（2FA）和政府身份验证，以及要求为脚本使用基于哈希的白名单。
总体而言，社区认为这些更新是降低长期存在的供应链风险所必需的“补齐”措施。
Alpine Linux 3.24.0 已发布，标志着 v3.24 稳定系列的开启。 **主要更新：** * **Python：** `py3-setuptools` 已升级至 82.0.0，移除了已弃用的 `pkg_resources` 模块；依赖此模块的项目需要进行迁移。 * **安装程序：** `setup-alpine` 现已支持 Limine 引导加载程序和 IPv6，并改进了无头设置（headless setups）的自动串行控制台配置。 * **桌面与软件：** COSMIC 桌面环境现已可在社区仓库中获取。此外，GTK+ 3.0 已移至社区仓库，同时移除了各种 GTK 2、Qt5 和 libsoup 2 软件包。 * **服务变更：** `qemu-binfmt` 服务已被弃用，建议改用 `binfmt.d` 配置。 **重要升级说明：** * 用户在切换大版本时必须运行 `apk upgrade --available`。 * 使用 GRUB 的用户需要运行 `grub-install` 来更新磁盘上的引导加载程序。 * 不受支持的配置（例如将 `/` 和 `/usr` 分离在不同的文件系统上）需要格外注意。 详细文档和完整的更改列表可在 Alpine Linux Wiki 和错误跟踪器中查看。
Hacker News
最新 | 往期 | 评论 | 提问 | 展示 | 招聘 | 提交
登录
Alpine Linux 3.24.0 发布 (alpinelinux.org)
22 分，由 fossdd 发布于 41 分钟前 | 隐藏 | 往期 | 收藏 | 2 条评论
帮助
Bender 1 分钟前 | 下一条 [–]
升级了其中一个节点。一切正常，没出岔子。
nginx -V
nginx 版本: nginx/1.30.2
构建自 gcc 15.2.0 (Alpine 15.2.0)
构建于 OpenSSL 3.5.6 2026年4月7日
已启用 TLS SNI 支持
unbound -V
版本 1.25.1
链接库: libevent 2.1.12-stable (使用 epoll), OpenSSL 3.5.6 2026年4月7日
链接模块: dns64 cachedb subnetcache respip validator iterator
回复
dizhn 2 分钟前 | 上一条 [–]
Alpine 真是一个精巧又美好的东西。
回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
二十年前，谷歌的“20%时间”政策为工程师提供了创新的空间，其根源在于信任文化，而不仅仅是日程表上的安排。随着企业对可衡量产出的要求将探索变成了“120%时间”，这项计划最终消失了——它变成了一种负担，而非一种特权。 如今，人工智能无意间重现了“20%时间”的承诺。通过自动化日常任务，人工智能为开发人员留出了探索的时间空隙，但这种“新20%”有着本质上的不同。它是以有限的人类注意力而非被许可的工作时长来支付的，往往会导致“人工智能大脑过载”——即管理多个自主智能体所带来的精疲力竭。 虽然这种转变赋予了开发人员新的创作自由，但作者认为，对于许多其他行业而言，人工智能是一种替代而非探索的机制。归根结底，历史先例令人担忧：生产力的提升很少使劳动者受益。当我们利用人工智能来争取创新时间时，关键问题依然存在：到底是谁收获了红利？这个效率新时代是会带来真正的创作自主权，还是利益会被顶层攫取，让劳动者去承担在一个节奏更快、更重考量的世界里所增加的压力？
这篇 Hacker News 讨论围绕着文章《谷歌的“20% 项目”已演变为 AI 的“120% 注意力”》展开，探讨了企业创新、人工智能整合以及网络内容真实性等主题。
评论者们回忆起“20% 时间”计划，例如谷歌著名的政策或 EA 的“周五下午项目”。虽然许多人表达了渴望拥有这种自由来解决内部技术债务，但另一些人认为，只有利润丰厚的“印钞机”企业才有能力补贴员工的副业项目。
讨论的很大一部分集中在文章本身，用户对其写作风格进行了审视。多名参与者怀疑该文章是由人工智能生成的，并利用 Pangram 等工具验证，发现文本中有很大比例显示出大语言模型合成的痕迹。这种讽刺——一篇关于 AI 注意力主导地位的文章竟由 AI 撰写——引发了关于 AI 是否已成为科技类标题党默认创作方式的广泛争论。最后，一些评论者表示担忧，认为 AI 进步所创造的“剩余价值”将流向监控密集型企业，而非个人创作者。
Blaise v0.10.0：原生后端、线程与增量编译 Blaise v0.10.0: Native Back End, Threads and Incremental Compilation
6 小时前
👍 1 人点赞 👎 1 人点踩 😄 1 人大笑 🎉 1 人喝彩 😕 1 人困惑 ❤️ 1 人点心 🚀 1 人点火箭 👀 1 人围观 您目前无法执行此操作。
Hacker News
最新 | 往日 | 评论 | 提问 | 展示 | 招聘 | 提交
登录
Blaise v0.10.0：原生后端、线程及增量编译 (github.com/graemeg)
5 分，由 mariuz 发布于 1 小时前 | 隐藏 | 往日 | 收藏 | 讨论 | 帮助
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
测试用例精简器（Test-case reducers）是一种强大却常被低估的工具，它能自动将庞大的输入文件缩小至能触发特定软件错误的最小版本。通过将繁琐的手动精简过程自动化，此类工具（如“Shrink Ray”）能够将输入大小缩减 90% 以上，从而大幅降低调试难度。
这一过程依赖于“兴趣测试”：即一个脚本，若错误仍然存在则返回成功代码，若错误消失则返回失败代码。由于精简器无需了解程序的内部逻辑，因此它可以应用于几乎任何文件格式。
高级用户可以通过自定义兴趣测试来设定特定目标，从而突破基础长度缩减的局限：
* **管理非确定性：** 通过要求错误在多次运行中持续出现，用户可以强制精简器优先选择确定性更高、更易于调试的输入。
* **设定优化指标：** 通过使用外部的“全局最优”计数器，用户可以引导精简器优化其他次要因素，例如执行时间、内存占用或日志长度，而非仅仅追求原始文件大小。
尽管这些非常规方法往往带有“黑客”色彩，但它们能将测试用例精简器从简单的实用程序转变为多功能的调试助手。
这篇 Hacker News 帖子探讨了**测试用例精简器**（test-case reducers，又称“缩减器”）作为调试工具的价值。尽管这些工具通常被认为只适用于顶尖的编译器开发者，但评论者们认为，更广泛的编程社区也应普及应用这些工具。
讨论主要突出了两个观点：
* **基于结构的精简**：用户 *mrkeen* 认为，手动且临时地进行精简效率低下。相反，他提倡使用基于属性测试（property-based testing）原则的“分治法”。通过根据结构定义生成数据，开发者可以对输入进行程序化的“缩减”，即通过不断降低输入的复杂度（“N”因子），直至定位到错误。
* **实际应用**：用户 *sigbottle* 分享了一个使用 **CReduce** 调试复杂问题的案例，当时死代码消除（dead code elimination）功能出现了故障。他强调，尽管起初尝试手动精简代码，但自动化工具极大简化了调试循环。
总的来说，该帖子认为测试用例精简是一种强大且未被充分利用的技术，它使调试工作从手动猜测转向了自动化的结构分析。