DGideas

@foolishcrab 哈哈哈，今天借着这个事情，我在三个文章回复底下尝试用 G 来做回复，还真的是语气不一样啊

Java 10 引入的 var 关键字和 Lombok 的 var 注解都是用来简化代码的工具。它们可以帮助程序员省略类型声明，从而让代码更加简洁易读。

然而，这些工具也可能会带来一些问题。例如，如果你过度使用 var 关键字，可能会导致代码变得难以阅读和理解。另外，使用 var 也可能会隐藏变量的实际类型，这可能会影响代码的可维护性和可读性。

一些公司可能不允许使用 var 关键字和 Lombok 的 var 注解，是因为它们希望代码保持一致性和可读性，并避免潜在的问题。因此，最好遵循公司的规定，避免使用可能引起争议的代码风格。

想象一下，以后的产品经理们只需要发一个草图就能生成前后端代码。而且，让 GPT-4 监控写脚本并自动处理报警，可以让我们更加专注于创意和设计，而不用花费太多时间在基础工作上。

但是，我认为技术的进步只是一方面。我们还需要考虑到人的因素。低端码农可能会被替代，但是他们也有自己的特长和价值。他们可能擅长细节和调试，这是机器无法替代的。而且，技术的进步也会带来新的需求和机会，需要不断地学习和适应变化。

总之，未来的技术发展肯定会带来很多改变，但也需要关注人类因素，同时保持学习和适应能力。

1. 对于 React 官方文档推荐 Next.js 或 Remix ，而不是 CRA ，这其实是一个很正常的决定。虽然 CRA 依然是一个流行的脚手架工具，但是 Next.js 和 Remix 更加适合构建复杂的应用程序，并提供了更多的功能和优化。同时，React 本身只是一个 UI 库，对于如何组织项目没有明确的建议，所以推荐使用更全面的框架也是可以理解的。

2. 确实，前端技术现在已经变得非常复杂，对于纯新手来说入门确实有一定的难度。但是，这并不意味着前端技术是不可学习的。相反，通过专注于基础知识、实践和深入学习，任何人都可以成为一名合格的前端开发人员。此外，社区中有很多很好的教程和资源，可以帮助新手们更轻松地入门。

3. SSR 有很多使用场景，比如搜索引擎优化、加速首次渲染、更好的可访问性等。虽然 SSR 可能不适用于每个项目，但对于某些项目来说，它是必不可少的。对于我个人的业务，SSR 在某些场景下确实带来了很多好处，比如提高页面渲染速度、提高 SEO 、提高可访问性等等。

4. 大公司把控的开源项目带来的技术风向确实值得关注，因为这些项目通常具有大量的资源、资金和专业知识，并且可以通过广泛的社区支持来维护和发展。但是，这并不意味着我们应该一味追随这些项目。相反，我们应该在深入了解和评估技术的基础上，谨慎地选择适合自己业务的技术，并在实践中不断优化和改进。

这些资料只要在 Google 上一搜就都有了

哈希冲突的相关信息可以看这里： https://en.wikipedia.org/wiki/Hash_collision

这里有一些 SHA-256 的哈希冲突的例子： https://crypto.stackexchange.com/questions/52578/are-there-any-well-known-examples-of-sha-256-collisions

同样地，MD5 会更简单： https://crypto.stackexchange.com/questions/1434/are-there-two-known-strings-which-have-the-same-md5-hash-value

如果能迁移到 GitHub 的话，可以考虑使用 GitHub CI ，外加私有 CI 服务器（如果需要）

https://dgideas.net/2022/using-github-actions-build-ci-cd-workflow/

自己尝试搭过邮件服务器，不过太麻烦了，最后还是放弃了，惭愧啊

如果需要免费的邮件服务器解决方案的话，可以如楼上所述，考虑下 zoho 海外版

你可能需要这个

https://frame.work/