@zzhaolei
@XyIsMy

一是: orm 本身是二次加工生成代码，不是直接 sql 语句不直观。日志 level 的方式打印出来的在复杂 orm 使用过程中、可能随着输入参数不一样可能做不到线上所有情况的 sql 范式覆盖，而且 orm 还有一些隐式的东西不是程序员自己设定的，比如一些 orm 库处理数据库的 null 值还是什么来着, 需要额外去绕过，具体哪个库哪些坑我记不清了，各位可以自己搜索引擎搜下或者官方 issue list 去看，我因为抵制 orm 所以对 orm 也没深入研究
二是，这也是更重要的一点，orm 培养了很多程序员的使用习惯、抛弃了 raw sql ，我见过的绝大多数初级中级同行、以及多数所谓的高级开发（至少八年十年以上经验），都是只要 orm 能实现功能就搞上去了，性能神马的都是事后线上出了问题再去搞。比如上面说的日志 level 打印出 sql 来, 但很多人习惯了 orm 开发方式这种思维，即使打印出来也不会去关注 sql 性能相关. 咱国内人口基数大, 中等规模的公司就可能经常遇到数据量较大的量级, 在做这类项目的时候、尤其是 OLAP 涉及大量统计汇总操作的，一个没留神就被 orm 选手搞性能事故了. 跟这类兄弟共事, 为了避免这些, 研发流程上已经做了很多把关, 但仍瑟瑟发抖.

@qW7bo2FbzbC0 #71
interface 满天飞是当时写这些垃圾代码的人的问题, 不是 golang 自己的问题.
正确姿势本来就应该避免 interface 满天飞, 我看到很多喜欢搞 interface 满天飞的, 是 php nodejs 之类的转 go 的人居多, 这也不能全怪他们, 毕竟以前语言习惯已经信手拈来了, 刚开始未必能意识到这样会带来工程上的问题, 更何况有时候赶工只追求先搞定业务
c/cpp 或者一些新手上路就是 go 的, 姿势正常的人多些

接手别人的屎山不是 OP 的错, interface 满天飞不是 golang 的错, OP 要怪就都怪写屎山的人吧

@james122333 我这个就是简简单单几点:
1. 鼓励明确定义 table 对应的 struct, 用明确定义的 struct 操作 sql, 这个 struct 自己手写也好用工具生成也好, 都挺方便的
2. 鼓励 raw sql, 避免 orm 之类的可能生成了性能不友好的语句造成性能事故
3. 框架尽量自动映射/绑定 sql table 和 struct, insert/update/select 这些与 struct 映射绑定操作密切的都很轻松用 struct 操作
4. 奥卡姆剃刀原则, 不提供 orm, 不提供那么多没什么必要的垃圾接口

@james122333
1. orm 是非常不好的选择, 中小项目倒是还可以, 大项目大数据量的, 用 orm 存在一些不确定性可能导致性能风险, 所以我都是禁止团队试用 golang orm 的
2. 还有生成代码的 sqlc 这种, 性能当然是最友好但用起来也有点麻烦, 因为一些业务是上下文比较复杂的, 单纯生成一段 sql 对应的 go 代码还需要 ctrl cv 而且还要修改对应的地方, 功能修改的时候比较麻烦
3. sqlx 简化了一些 binding, 但也把一些简单的复杂化了, 比如又有 Select 又有 Get, 比如 Insert 缺少 struct 的自动绑定(我没深入使用只是看它文档和例子), 综合下来我觉得它少了一些可以真正节约体力的但多了不少没必要的, 所以对我来说病不好用

所以以前还是继续标准库 raw sql, 直到我实在忍不了标准库 raw sql 自己搞了这个

定义跟 sql table 对应的 struct 是必要的, 自动绑定后用 json 去操作 struct 就没这个问题了.
个人觉得 orm 不好用, 自己搞了份 raw sql+自动绑定的库, 有兴趣可以试试, 例子:
https://github.com/lesismal/sqlw_examples/blob/main/mysql/db/db.go#L101

这种纯数据结构本身就不应该设计成返回 error 的，其他语言这种数据结构也没见过返回 error 之类的啊。。：
https://github.com/golang/go/blob/master/src/container/list/list.go

A1 这种直接查 map 就行了，无需遍历

### 查表法
1. A2 这种涉及顺序的，可以使用查表的方法：
开奖结果的 hash 值作为 mapA 的 key ，因为是 5 个数字而且彩票这种数字通常不大，一个 uint64 甚至 uint32 就足够做 hash 值了。每个奖期信息作为 value 并且排序后的数组作为 map 的 value 。如果用 c++，multimap 内部红黑树自动就是排好序的，不需要自己排序数组之类的

假设不同的下标为 targetIndex=0, 然后就只要查 map hash 值得到相同的、如果不等于 targetIndex 就找 targetIndex=当前 index+1 并查找下一个 hash 相同的。当然，如果遍历平均为 5 、开销也不大, 那这种可能不划算、根据实际测试情况、可以考虑就用遍历

2. Q15B/Q15R/P15B/P15R 这些，都可以用对应期段的数据建各自对应的表，然后直接查表就能计算出 key 对应的 value 数量，不需要遍历几十期、匹配上则+1 的方式去计算

这个过程中只建表一次，然后上面的 1/2/3 都是直接查 map 就出结果了

### C618
建表的过程可以同时根据期号做倒排索引，C618 回退 618 期、计算每期时，把上述过程中建表的只需要删除临界的一期、加入需要的一期，所以这个过程中不需要重复建整个表，只是滚动删、增一期，整个流程的建表开销不需要太大


我不了解实际需求，以上仅供参考

搜了下:

安卓的历史始于 2003 年 10 月，远在智能手机这个名词被广泛使用之前，也比苹果发布第一款 iPhone 和 iOS 早几年。其四位创始人分别是里奇·米纳、尼克·西尔斯、克里斯·怀特以及我们较为熟悉的安迪·鲁宾。援引当时鲁宾的话说，安卓是为了开发“更智能的移动设备，更了解用户的位置和喜好”。

鲁宾在一次演讲中透露，安卓最初是为了改进数码相机的操作系统。但即使在当时，数码相机的市场也在萎缩，仅仅几个月后，他们就决定将安卓的定位转向在手机内部使用的操作系统。

@xliao #9 文章开篇说明作者身份 "I was a young..." , 年轻人水平不够的阶段随便搞这种重构确实容易坑, 所以他的文章不能说明 rust 不行.

> 大内存，这点 go 做的不好，固定频率的 GC 在大内存占用时停顿明显。毛刺明显

go 的 gc 已经很丝滑了, 多数人的业务量也不会有瓶颈. 我这里的百万连接的对象 map 优化下确实省不少:
https://github.com/lesismal/nbio/pull/304#issuecomment-1583880587

其他很多场景也可以定制数据结构针对性优化 gc

至于调 gc 参数, 对于一些常驻对象数量大的, 仍然不太好解决根本问题

转:

YouTube 似乎在测试服务器端广告注入以对抗广告拦截器

YouTube 通过服务器端广告注入继续打击广告拦截工具。广告拦截软件 SponsorBlock 的开发者今天分享说：“YouTube 目前正在测试服务器端广告注入。”从高层次来看，这意味着广告现在是作为视频的一部分，被流式传输到你的设备，而不是单独投放到桌面网页或移动客户端。目前的方法允许广告拦截器拦截并且不显示广告。但未来广告会与视频无法区分。目前该功能仍在测试中，部分用户已经遇到了这个问题。

@arloor 对, 所以高通 arm 或者 intel 新代稳定后才是更好的选择, 只是需要等等:

https://www.youtube.com/watch?v=b3FTtvPcc2s

https://www.youtube.com/watch?v=uB1YTO0RDVg

> 其他的没建议，建议了解下 14 代 I7 的相关问题，例如功耗过高以及 I7 、I9 不稳定的问题。以免装了之后才知道这些，膈应

@arloor 恰好刚出的消息说是原因找到了：

https://www.msn.com/zh-cn/news/other/intel-13-14%E4%BB%A3i9%E4%B8%8D%E7%A8%B3%E5%AE%9A%E7%9A%84%E6%A0%B9%E6%BA%90%E6%89%BE%E5%88%B0%E4%BA%86-%E5%B9%B6%E9%9D%9E%E4%B8%BB%E6%9D%BF%E5%8E%9F%E5%9B%A0/ar-BB1ofXxw

Intel 13/14 代酷睿 i9 K 系列大规模爆发游戏崩溃、蓝屏死机的不稳定问题已经一个多月了，但除了主板厂商更新 BIOS 设定，Intel 一直没有针对这一情况公开发声，原计划在 5 月 31 日发布的官方声明也没了下文。

根据 Igor'sLAB 的最新报道，Intel 终于找到了这一问题的根源，不是主板 BIOS 的设定有误，而是出自 Intel 提供的微代码算法本身，并已在内部复现。

确切地说是，eTVB 加速机制的参数设置错误，导致在较高温度下，频率和相应电压的提升，降低处理器的稳定性，13/14 代酷睿均受影响(CPUID 0xB0671)。

Intel 的一份内部文档中解释说，对于 13/14 代酷睿 K 系列的失效分析显示，因为电压持续处于较高的水平，处理器的最低运行电压出现了偏差，而之前的微代码和 BIOS 设置有误，允许处理器在高温下依然可以运行在加速频率和高电压之下。

至于 12 代和更早的酷睿 K 系列，因为默认电压和频率较低，对这种设定不敏感，因此不会出现不稳定的情况。

Intel TVB 、eTVB 加速技术仅支持 i9 ，这也就是为什么问题集中出现在 i9 系列上——虽然部分 i7 K 型号也偶有不稳定问题，但不是同一回事儿，可以视为其他原因的个例。

TVB 技术是在睿频 2.0/3.0 加速之外，根据处理器的功耗、散热冗余空间，进一步超频。

比如说 i9-14900K ，官方标注的最高频率 6GHz 就是来自 TVB ，而常规睿频 3.0 的加速频率最高为 5.8GHz——就是这区区 200MHz 惹了祸。

Intel 已经要求所有主板厂商，在 2024 年 7 月 19 日之前将微代码版本升级到 0x125 或者更新，其中包含一个 eTVB 修正补丁，当温度超过一定阈值后，就不再允许进入更高性能状态，也就是限制超频。
相信很快，Intel 就会发表公开声明，主板厂商也会陆续更新 BIOS 。

@murmur #4 年过 35, 又很多人说：劝人 IT ，天打雷劈。除了失业，多数人还一身 IT 职业慢性病。
压力和收入是早来还是晚来放到一辈子人生的尺度上，在不同的时代各具优劣。比如 10 年前，如果搞 IT 先攒够第一桶然后赶上互联网红利、房地产红利，划算，但是当下的经济周期区间就未必了

@MIND222 如果分数能有机会，建议军医。原因：
1. IT 或者其他前沿那些想在做出成就的赛道竞争压力大，成绩不具备优势，所以不建议
2. 相比于普通医学方向，军队国防生本身的待遇不差，有军队管教只要跟着别掉队就行，技能点上也是长期价值的投资，年轻时候辛苦点，稳定无忧

先搞清楚要对比的是什么, 如果是 count(*) 对比 count(user_id) 是有可比性的, 但 select * 对比 select user_id, 每条 700B vs 每条数据最多 8B, 单说拷贝 100w 条数据的量就性能差别巨大了所以二者根本没有可比性

只考虑孕妇、不考虑孩子吗？随便搜了下对孩子的影响：

增加儿童恶性肿瘤的几率
引发儿童哮喘
影响儿童听力发育
影响儿童身高
诱发厌食
影响儿童智力发育
婴儿猝死综合症
...

女人不懂事那自己爱吸就吸，孩子面前谁抽烟都不行！

提前客气地给客人说清楚，忘了就再提醒，平常语气沟通，不用纠结什么客气不客气的
别惯着这些坏习惯

@iseki
什么情况必须获取原始口令？密码和 OTP 是有区别的，你要说 OTP 我没意见。其他系统的密钥本身，我暂时想不到必须用原始明文口令的。
我的出发点是，实现各种密码存储需求本身要应对的业务，并不需要以来明文本身，历史问题是历史问题，但这里说的是方案本身的优劣，历史改造甚至都不在我考虑范围内
所以这根本不是说法的问题，是逻辑本身的问题，如果你一定要用“现在已经有哪些使用了明文、所以避免不了用明文”来讨论，那确实没什么可讨论的了，这不是我在讨论的问题

@lesismal #222 不要看它当前是什么方式，站在当前实现的方式的角度考虑问题则任何现状都有它局限于历史和版本等问题导致的合理性。应该撇开历史现状，看理论和实现方法上，哪种方式可以做到更好。是否把旧系统改造升级是项目自己的管理的问题

@iseki LDAP 我没太了解过，但如果它需要明文的密码，这应该也是历史遗留问题，因为本质上是不需要明文的。另外，“必须把用户输入的原始口令发送过去”—— 这里的原始口令要看是哪种，如果是密码、那是历史实现问题和现在的兼容性、修改成本问题，如果是 OTP 这种单次验证码，则没关系，单次的验证码明文也可以、不怕泄露