幼儿园我们每学期都有体检和视力检查 防近视主要规范平时的用眼习惯
一定要多关心小孩的视力情况 及时纠正
不要迷信户外就一定没问题
就算是户外画画 一直盯着画板不休息一样近视
关于视力这个 遗传风险相当高
如果父母没有近视 小孩的远视储备一般会非常强
除非用眼习惯特别恶劣 但也比父母近视加上用眼习惯差的小孩好很多

怕小孩容易生病 最好在换季前流感疫苗安排上 不能说百分百有效 但症状上能减轻很多

@travelinglight #4 我们老师不建议托管或上延时班 除非双职工真的没办法 有这个政策是因为上面有要求 给家长减负 因为小孩在幼儿园上了一天 到下午四点左右 已经明显有精神和体力的疲劳 你这个幼儿园居然还可以上到六点半 我们托管最多到五点 现在小学只报了一个游泳

上她喜欢的就行 其实就是兴趣课托班 只要小孩感兴趣 哪个都行
都是以游戏兴趣教学 小孩开心最好
除非天生体质较弱 要不然不要把小孩体质想的那么差
我家今年二年级了 学校一大堆外聘特色延时课
一年级的时候还感兴趣 现在跟我说那些课太无聊了 一个都没上
比如羽毛球课 上了一学期 只教了发球

挂历 https://i.imgur.com/agAJ0Rd.png

@wbrobot #1 恢复试过了没有用 开机阶段就开始白屏 感觉应该是硬件老化了 也拍过了 不太管用 https://i.imgur.com/agAJ0Rd.png

马云还说 996 是福报

@aababc 你喜欢改完实体，最后统一 Save ，
再让 ORM 自动追踪哪些字段变了 你配合 Gorm 一样可以做到
我要表达的是 业务层说清楚要干什么，Repo 负责怎么落库
不一定要让 ORM 接管整个 Entity 的生命周期

这么跟你解释 你可能清晰一点 不是每个更新组合都要去写个方法
那就是为了抽象而抽象 简单的 repo 可以这样
如果特别复杂，更新组合比较多那 repo 方法也会爆表
当然也不符合 Go 的项目开发最佳实践
这时候，你甚至可以定义个 update 结构体，然后去传想要的字段调用它

type OrderUpdate struct {
Status *Status
Paid *bool
PaidAt *time.Time
Amount *int64
Remark *string
}

repo.Update(ctx, id, OrderUpdate{
Paid: ptr(true),
PaidAt: ptr(at),
})

这样做的话类型安全 只更新想要的目标字段
但零值需要谨慎考虑 终归到底你需要的是一个类型安全的 DTO
没有谁对谁错 但既然从 PHP 转到 Go 我觉得也应该遵循这个生态的实践经验
要不然 直接用 Hyperf 不好嘛
无缝对接 Eloquent 以前怎么爽写现在就怎么爽写

@aababc 当然可以 但是 Go 强调的显式、类型安全、清晰
你这样做 本质上又是在自己造一个弱类型的 ORM 更新接口
做法不是错误的 但是不符合最佳实践 失去类型安全
很容易变成万能的 Repo 从你发帖到回复 你一直都在往这个方向靠齐
说明你受原来的开发思维影响太严重了

如果业务已经明确知道哪些字段发生变化，直接通过 Repo/ORM 的 Updates 、Select 更新对应字段就行，不需要 Dirty Tracking ，让业务层明确告诉 Repo 要更新什么：比如 repo.MarkPaid(ctx, id, paidAt)

@aababc 持久化当然少不了，但业务变更并不等于必须使用 Dirty Tracking
正常的持久化方式本来就是修改什么字段就更新什么字段
你需要的是 Dirty Tracking 能力 用 Gorm 也可以实现
另外从你的代码中能看出 你的职责边界设计比较混乱
order.Pay()已经完成了业务行为，repo 的 Paid(order)实际上又在表达一次
你的 repo 耦合度非常高 Paid 接受一个完整的 Order 然后自己去判断需要的字段
你这不又把领域状态和持久化逻辑耦合在一起了吗？
repo 更合理的职责应该是负责把要持久化的数据存取出来
而不是重新解释业务 Usecase 也有重复的表达
使用 Go 来开发项目都有默认的潜规则 就像共有方法前缀一样
Go 经常在不同层故意使用相似的 struct ，是为了解耦
推荐多看看 Go 的项目最佳实践

你这是刻意在把 Doctrine/Eloquent 那套 Entity 的思维迁移到 Go
Go 的优势跟你的习惯相反 不强迫你把 DB 和领域实体、持久化生命周期绑在一起
Go 设计思路应该更多地在表达业务，而你更多思维是在表达 ORM
这会更接近 Go 业务系统里比较舒服的设计 要把编程思维转换过来

https://i.imgur.com/KWHtXQE.png

cursor 主要是 composer 和 grok 量大管饱
如果按照那种方式蹬 pro 套餐 不到半天三方模型的额度就没了
如果还想用 开启额外收费 那性价比就太低了

你要是真用过 cursor 的第三方模型就不会这么问了

https://imgur.com/a/bNTaBT0

@allforone 你当然能表达你的观点 但我也有我的看法
你说的浪费仅限于你的使用方式 因为你把它的额度当成固定的 quota
而它的额度本身就是滑动窗口 反复随机的重置并没有损害你的周期内的配额权益
你前两天可以正常用 第 4 天也可以爽用 只是随机推移了你的期望重置时间
平移了你想要的爽用时间 打乱了你的使用的方式
我用 cursor+codex ，但我的使用方式和你不一样
我能充分利用它们的配额 因为我不是攒着用 我在订阅时 先确定对应的 plan 是否够我用 1 个月
如果赠送了 那我用爽一点 蹬狠一点呗 跟你说的一样 max 拉满
但我会控制滑动周期内的总进度条 如果一直赠送 我就能一直爽用
未来如果 codex 推出了固定周期 那么你就是最大的受益者
所以说这个规则只有合不合适 没有对错

@allforone 没关系的哥们 你尽管 B 就是了 不过说到理解能力 既然你是 x20 倍尊享 VIP 你把他送你的蛋当做有毒的不吃不就行了吗 还是说你看不懂百分比 或者你心里也眼馋重置呢

@allforone 如果你理解能力差，你只需要记住到目前为止大概吃了多少蛋，因为你的蛋只有 30 个，送的多无非篮子里满了而已，会干预你吃蛋计划对吗，哥们，太抽象了。

@allforone 如果送的蛋不过期就好了，这样我就可以攒着后面吃。招笑。