抽奖为什么不能脱离惯性思维呢。人都是在被事逐步逼紧才会疯狂分泌激素。
要想氛围好，反相抽奖，先抽到的出局，仍在局的人会一直紧张并幸灾乐祸出局的人，而随着逼近的中奖结果，越晚出局的人越容易惋惜。大部分人不会因为谁中了奖而开心，而会因为你也不中奖而大笑起来。
70 人一个一个抽，抽中就出局，剩下 15 个那就是都得奖，再继续抽中的就三等奖，三等奖抽完，抽到最后 3 人就是一等奖。

固态这么便宜，就别 1T 了，我 618 装机搞了宏碁掠夺者 2TB 。

@qq309187341 感觉你可能迷惑的点是存在数据库里的时间字段，其实数据库也是有时区的，你设置了 datetime 格式的字段，显示的是 2023-01-01 00:00:00 这样的格式，如果你数据库设置了 0 时区，那你就在理解上加 8 小时就好，如果是东八区，那就跟我们北京时间一致。
你服务端用 UTC 格式的时间去存数据库，数据库自己会根据自己时区去转换好时间存进去，显示的是数据库时区的时间。我没具体去测过这块，你可以试一下，给数据库不断换时区，看下是不是这样的表现形式。

@qq309187341 其实你小项目也涉及到时区，只是估计你部署的服务器默认给你的是亚洲上海时区而已，然后你前端也是东八区，自然就刚好对上。如果你服务迁移服务器或者用 docker 容器部署，你服务有可能就基于 0 时区上，那你前端展示的时间就会少 8 个小时。这就是隐患。
至于方案，用标准时间包去做时间处理就好了，其实就是带着时区的时间去做交互和转换，这样谁都知道这个时间是表示哪个时间点，至于字符串格式的时间 2023-01-01 00:00:00 ，在于 24 个时区就有 24 个不同的时间。所以，如果是后端的活是不要推给客户端，但是该是客户端的活，也不要揽下来，各自负责各自的责任。前端业务要显示 YYYY-MM-DD 或者 DD/MM/YYYY 格式，那就让前端自己用时间处理包搞，后端负责返回标准时间格式就行。
再说下时间戳，可以理解为 0 时区的 UTC 时间，但是我一般不用，放数据库里不直观，查个数据还得转换一下才能理解。

@YEX1024 说的在 entity 里转是对的。但是你要这样去用来转时间的逻辑是错的。所有的时间交互都应该带时区或者用时间戳，无论是入口还是出口，显示端根据自身时区去做格式化展示。而你这样直接服务端处理了，就相当于前端页面在全球都是展示你服务器时区的时间，明显是有问题，当然，只考虑自己时区无所谓，也不会拓展的话，但是终归是不标准。

@zexinwu84 我就在品秀星图，160 买不到

一切以小家安稳幸福为前提。夫妻有想法上的差异是很正常的，客观的摆在台面上谈，确实局内人容易被情绪左右，不容易看清局势。

借钱，其实就是在送钱，在本金能回来的前提下，本来是提前还款的钱，按不加点的商贷 4.9%算，就是在为借出去的钱付利息。

有多大的屁股，就买多大的内裤。6W 已经是 3 成现有的资产了，是一个很合理的比例。按我的想法，这个是在没前债的基础上，有前债没还，要么不借，要么亲弟亲姐也最多再借个一两万。

存在风险过高。24 万需要借 10 万，证明收入实力一般般。按正常来走，加个房贷后，还钱能力及其微弱，更别谈抗风险能力。所以按客观逻辑判定，借多了相当于半借半送，根本没有充足的还钱能力。

家庭的意义。组建了自己的小家后，无论男女都是首先是属于小家，其次才是属于大家。努力工作换取资源（金钱）是为了组建的小家追求幸福愉悦的生活，而不是辛辛苦苦为其他人所付出。别人的小家做出超出了自己能力范畴内的事，凭什么需要你的小家来承担。说实在的，为自己的小家，每个人都应该更自私一点。

经验所得，跟我前两年的遭遇一样，不过差别在于，我跟我老婆的想法一致。借多可以，约定了短期内还一部分，不然就借少点。每个人都应该把握一个 [度] ，别人的 [度] 越了，你不能牺牲自己的 [度] 来成全别人。

[没有原则上的问题，不要轻易放弃小家]