定义跟 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 这种单次验证码，则没关系，单次的验证码明文也可以、不怕泄露

@morebuff 感谢支持！欢迎使用！ 666

首先应该清楚：他俩可不是普通人啊

所以，为什么要用普通人对比做标题

> 明文向后端传输虽然不好

你看, 你也认为明文不好了

> 但有时这是工程上成本刚好可以接受的方式

如果是项目初期/上线前, 这个成本真的不多

> 一来我刚才说了，很难设计一个有足够收益的非明文传输方案

数据隐私本身不重要的网站, 明文与否都还好, 即使泄漏了也没关系. 我自己注册一些不重要的网站的密码都非常简单, 单手输入满足大小写之类的就用了, 也不怕泄漏, 重要信息的网站就复杂些而且那些站多数有二次验证之类的额外安全措施, 所以也不怕

> 二来就是有时候后端的某些设施只能接受明文

密码这个功能点上来讲, 明文不是必需, 所以如果哪家说必需明文, 那我怀疑这是别有用心...

@iseki

@zanpo 兄弟你根本就没看懂 OP 我说的是什么, 你们好些位这都相当于是盲人摸象管中窥豹, 只考虑 https 或者某个 part, 请先看下我帖子和 append 或者更多楼层的回复