@geelaw 那的确应该去找特定的邮件发送服务商了，我后续研究下，感谢

@geelaw 谢谢，我们面向的是海外客户注册，不能使用国内的服务，sendGrid 正好是海外的，我后续调研一下

@geelaw 这是 zoho 的 smtp 文档，也没提到能不能用于发送注册验证码，https://www.zoho.com.cn/mail/help/zoho-smtp.html#alink5

@geelaw 查了一下公司注册域名，配置了企业邮箱是 zoho 企业邮箱，我把这个企业邮箱的 smtp 功能开了，如果用 python 的 smtp.sendmail 应该就能直接发送邮件了吧，看起来跟 @dzdh 提到的 sendcloud 的里面文档的发送方式并无区别：

这是文档
https://www.sendcloud.net/doc/guide/base/#smtp

因为是自己申请的域名配置的企业邮箱，理论上用来发送邮件验证码应该没事吧……

@dzdh 所以企业邮箱，也是直接启用企业邮箱 smtp 服务，然后用代码 sendmail 吗，并不需要特定的 api 服务

resendcloud 查了一下，可以通过 API 发送的，但文档里面也写了能通过 smtp.sendmail 发送，也就是说 smtp.sendmail 就是标准用法，会不会进垃圾箱主要看是不是企业邮箱？

@zsmile 这样的回答就是农民说我可以用镰刀收麦子手动打谷，所以和收割机功能一样的回答

事实上其他语言都有了统一的解决方案，mybatis 还在看具体场景分情况分析，用 sql 更是原始时代的做法，总不能认为就 mybatis 的路线正确，其他所有语言的路线都错了吧……

矛盾论里面一句话就说明了。

形而上学，亦称玄学。

@zsmile 关键是解决方案是怎样的……

@zsmile N+1 是行业通用的术语，每个 orm 框架都要必须解决的问题，但 java 开发者很少知道这个术语，属于对外界了解不足，mybatis 解决 N+1 的方案，上网搜了一下，都很繁琐，完全没有使用 orm 框架的优点

@zsmile 不能只学一种语言，一种框架，会导致视野局限，只要了解了 3-5 种之后，很快就能理解哪种方案更优，大部分 orm 框架实现都在往一个同样的方向，建立数据库无关的模型层，通过定义表之间的关系自动解决 N+1 问题，自动嵌入预查询，通过语义化的查询替代 sql 。

类型做的更好的语言，C#，直接将数据库字段映射到类型上面，重载运算符，直接在语言层面上实现的 sql 语句的转化，python 弱一些，但基本也做到了这一点，php 的类型更弱一点，直接追求灵活性，不追求数据库字段的描述，实现代码数量大幅降低，但缺点就是字段都是文本描述，无法利用编辑器的提示。ruby 则是彻底追求灵活性，直接用元编程将字段映射上方法上面去，可以自动生成方法 find_by_name 。

评价一个 orm 的好坏，api 设计风格不提，至少要能优雅的解决 N+1 问题，我问做 java 的朋友，很多人连 N+1 问题是什么都不知道……

@haython relation 关联中的 with ，解决 N+1 问题
withCount, withSum 这样的聚合函数，解决统计问题

可以看一下文档： https://laravel.net.cn/docs/11.x/eloquent-relationships#counting-related-models

@haython 例如给古代的农民讲解收割机怎么先进，农民听了会说，我用镰刀也能割麦子，割完打谷也能得到麦粒，这个收割机也没什么大不了的，没办法做到我做不到的事情

@haython 用过 laravel, ruby on rails, ef core, sqlalchemy 就知道什么是先进了，如果没用过，就算描述出来，也只会觉得，mybatis 也能做到啊，只要这样这样这样，就可以了

纸上得来终觉浅，绝知此事要躬行

这么多年，没见过一个人认为有钱不好的，不知道为啥还要悟……

@JoeDH java 是只学过 jpa 和 mybatis ，没在实际项目中使用过，实际用过 C#的 ef core ，ruby on rails ，php laravel ，python sqlalchemy

从我的实际体验中，ef core 最强大也最完备，可以拥有完美的 ide 支持，ruby on rails 最灵活但完备性不足，无法依赖编辑器的高亮提示，laravel 和 rails 差不多，灵活性差一些，但完备性好很多，sqlalchemy 有点类似于弱化版的 efcore

jpa 方向是和这些 orm 框架一致的，但实际使用太繁琐了，mybatis 不能叫 orm ，只能称之为 db_tool 工具集

@zsmile 瞄了一眼 jooq 的文档，Api 设计的也很一般，还是建议多看看其他语言的 orm 框架，感觉 java 的 orm 设计者都没看过其他语言的 orm 设计，明明其他语言的 orm 设计都是相互借鉴的……

springboot 不落后，mybatis 是真的落后……

表结构尽量简单，确保查询要走到索引，复杂查询拆开，便于优化，上 SSD ，读写分离，可以支撑到 10 亿级别数据
再往上可以用分区功能，我的经验只到 20 亿级别，没有开分区，也扛住了。