小天管理

活动时间： 2024.7.6-2024.7.20 活动规则： 1.凡在活动期间通过链接 https://app.pokepay.cc/pages/passport/invitation?r=100668 注册的 pokepay 新用户，均赠送 20-12.8U 的虚拟卡开卡券一张。可用于开虚拟星际卡，实付只需 7.2U 2.凡通过链接注册并完成 KYC2 实名认证的新客户，均可支付 20U 获取一张 108U 的万事达香港实体卡开卡券.可用于原价 108U 的 pokepay 实体卡开卡使用 3.虚拟卡开卡券数量不限，实体卡开卡券限前 15 位，数量有限，先到先得。 4.虚拟卡开卡券注册直接赠送到账户，实体卡开卡券需完成 KYC2 实名认证后联系 tg@redotpayfans 提供 kyc2 实名通过截图，告知注册邮箱，并支付 20U,24 小时内发送到注册账户。 5.通过链接注册开卡用户，可享受香港 0 月租免实名插卡即用 sim 卡 10U 包邮优惠。 香港 sim 卡可用于注册香港支付宝，可直接绑定 pokepay 实体卡在内地扫码支付。香港支付宝新户必得 50 大毛，每月 18 港币优惠券，每月 10 次最高 188 港币立减等优惠。

有运营微信公众号的吗，有无这感觉

4k 图标是可以点亮的，播放的时候实际码率锁死在 1080p ，之前好像没问题，有什么解决方法吗？ uwp 倒是没问题，但是听说 uwp 会下架。

现寻思也没下载和干啥，后台长年不挂默认无，开虚拟内存不至于吧，又不是 3G 那会，Windows 都没你那么凶的。目前就一直占着空间，DFU 好几次，使用几次又老样子了，求懂得老哥看看

真是不用不知道，一用吓一跳，最近有些需求需要处理一下硬盘，没想到居然只有自带的 Disk Utilty ，连个好用的工具都没有，有大佬有 mac 上的推荐么

RT ，求各位 V 友帮忙解答一下，有没有好一点培训机构推荐啊？

用了好多年，一直很稳定，没想到跑路了。之前都是春节一年 150 左右价格买得（每个月 200G ），求个差不多价格得平替。谢过佬友了。

github 地址： https://github.com/ypq123456789/change-root-password 抢机子自己的手速总是不够快，总是抢不过别人，那只能借助科技的力量了。借助 claude 一晚上弄出来的，枪机必备脚本 Change Root Password ，求鸡腿、求 star ！可以拿快过期的机子测试使用，千万不要拿自己用的机子轻易尝试！ Change Root Password 这个脚本用于快速修改 Linux 系统的 root 密码和 SSH 配置，抢机必备。它主要用于临时 VPS 的快速配置，不适用于生产环境或长期使用的个人服务器。 警告 注意： 本脚本只适用于快速改 root 密码抢别人送的 vps ，不适宜用于自用机子，更不适用于生产环境，如果你在自用机子和生产环境上使用本脚本导致无法连接上 ssh ，后果自负！！！ 功能 自动更新脚本到最新版本 修改 SSH 配置以允许 root 用户密码登录 生成随机密码或允许用户自定义密码 更改 root 用户密码 重启 SSH 服务以应用更改 使用方法 方法 1：使用 GitHub API （推荐，版本最新，部分机子可能 403 报错） 这种方法会自动获取最新版本的脚本： curl -s https://api.github.com/repos/ypq123456789/change-root-password/contents/change_root_password.sh | jq -r .content | base64 -d > /root/change-root-password/change_root_password.sh && chmod +x /root/change-root-password/change_root_password.sh && /root/change-root-password/change_root_password.sh 方法 2：直接从 GitHub 下载（版本可能滞后，上面的 403 报错再用这个） 这种方法直接从 GitHub 仓库下载脚本： curl -s https://raw.githubusercontent.com/ypq123456789/change-root-password/main/change_root_password.sh > /root/change-root-password/change_root_password.sh && chmod +x /root/change-root-password/change_root_password.sh && /root/change-root-password/change_root_password.sh 注意事项 脚本需要 root 权限运行。 使用此脚本可能会更改您的 SSH 配置，请确保您了解这些更改的影响。 在更改密码后，建议在新的 SSH 会话中测试新密码，而不是直接断开当前连接。 此脚本不适用于生产环境或重要的个人服务器。 贡献 如果您发现任何问题或有改进建议，请创建一个 issue 或提交 pull request 。

庆祝 Infuse 通过 ICP 备案活动 🎉 我们非常高兴地宣布，Infuse 在中国的 ICP 备案工作已顺利完成，我们将持续在中国 App Store 上提供更新！👏 为了庆祝这个激动人心的日子，我们为 Infuse Pro 提供了超值特惠。 只需 ¥18 即可获得一年的 Infuse Pro ，比正常价格便宜 80%！ 输入邮箱地址，即可在数秒内收到您的专属优惠代码。 提示：兑换码仅限在 iPhone 或 iPad 上使用，且必须在 2024 年 7 月 9 日之前兑换。 https://firecore.cn/promo ICP 备案号：沪 ICP 备 2024080644 号

以下的讨论范围局限于前端后端搭伙一起干功能的业务场景。（不涉及提供 public API 之类的场景） 简单到复杂 最初没有专职的前端， 页面的渲染都是后端的工作 当浏览器功能复杂到一定程度，页面需求上升到一定程度，并且前端框架开始成熟， 独立的前端工种开始出现 随之而来的变化， 是组织结构上，前后端的“分工”， 为了术业有专攻。 但伴随而来的问题是， “沟通”和“迭代” 成本的上升。 以前后端写页面的时候， 这也算是一种古老的全栈，一个人写节省了沟通成本。 并且通常会在 controller 中提前把需要的数据组装好再 render 到页面 在分工的模式下， 一个功能，一个 story 需要至少两个人来一起完成。 一人负责提供 API ， 另一个人负责消费 API 来构建页面。这些人都要参加需求会议， 还要保持一致的理解。产品遇到问题的时候， 往往就是先问前端， 然后排除前端嫌疑后再问后端， 路径就比较曲折， 前端也不胜其扰。 后端给 API 会有两种选择， 可复用的功能， 做成通用 API 。尚不清楚全貌的功能， 做特供的 API 。通用的 API 可能会在多个页面都有用到， 产生了多个依赖。 但业务总是在迭代， 早前通用的 API 可能变得不通用， 导致的结果要么是后端对其做特殊的扩展， 要么是前端做多 API 的组合。 （如果之前多个页面依赖了一个 API ， 则排查和调整的工作会更加复杂） 因此出现了技术债，API 参数变得复杂，前端则混入了组合数据的”业务逻辑“。 局部最优 不代表 全局最优 引出了一个观点， 在前后端合作的项目上，不要去考虑”可复用的 API”， 应该考虑可复用的“服务”。 后端如果开始考虑 API 复用来减少自己的工作， 这可能往往就是麻烦的开始。 API 只是一个和页面相关联的“管道”， 每个页面有自己独立的“管道”， 和后端“供应商”。这样后续的维护和迭代才能容易。每个页面严格扮演好后端对应服务的展示层（ presenter)。 如果发生了需求改变，影响的范围就只会出现在纵向，不会出现之前“改个 API”， 结果某个其他页面报错的意外。 前后端分工后的另一个趋势是， 前端开始插手数据的处理，换个说法是开始做业务层相关的事情。 原因从可以从分工减少沟通的角度来解释，也可以从“充分利用”浏览器性能的角度来解释。 但这样做带来的后果就是一个完整的业务逻辑被分散到了前后两端，这对业务的完整理解就会有害，而且越是迭代频繁的项目，这样做的麻烦就越多。 有一个概念叫做业务的本质复杂度，很多时候前后端分离模式下的代码的实现会在这层复杂度上增添厚厚的一层额外复杂度。 马丁福勒在《企业应用架构模式》中说： 处理领域逻辑时，其中一个最困难的部分就是区分什么是领域逻辑，什么是其他逻辑。我喜欢的一种不太正规的测试办法就是：假想向系统中增加一个完全不同的层，例如为 Web 应用增加一个命令行界面层。如果为了做到这一点，必须复制某些功能，则说明领域逻辑渗入了表示层。类似地，你也可以假想一下，将关系数据库更换成 XML 文件，看看情况又会如何？ 上述的这种情况在前后端分离模式下是很容易出现的。 后端想着做通用接口， 前端想着做更多的事情， 两边的磨合的产物就是 BFF 。 BFF 模式的诞生 (其实算是个 controller 层) BFF (backend for frontend) 出现的是引入了一个新的中间层，让后端专注在通用的的服务， 让前端专注在页面。 它来干中间的脏活， 构造特供的 API 。 他的责任是从多个数据源聚合数据，然后将处理完整的数据提供给对应的前端， 从而避免不必要的前端业务处理和数据转换操作。 如果后端 service 的封装良好， 可以让前端在一层理想的业务抽象之上开发功能。 BFF 通常由前端来维护， 在 BFF 模式下，BFF + 前端 组成了一个轻量级的“全栈”开发模式。它区分了领域层和展示层(presenter)。 这种分层在单体应用上对应的分层为 service, controller 和 presenter 三层。 约等于后端负责 service ， 前端负责 controller 和 presenter. service 提供业务逻辑封装 controller 组合各种业务逻辑， 满足各种灵活多变的数据需求 presenter 展示数据 主流方案的比较 当前主流的 BFF 方案有 graphql ，trpc 和基于 openapi 的 RESTFul 。 graphql 存在引入成本较高，前端需要书写查询的 i 问题， 还有其他 graphql 的特有国情。 trpc 很好用，但限定了后端为 ts ， 约束了后端选型 综合来看，openapi 的 RESTFul 接口，配合 openapi-ts 这类方案是最友好的，兼顾了后端实现的自由度和向前端提供类型和 client 的便利。而且整个的引入成本也很小， 有不少的框架都支持自动生成 openapi 接口文档。 另外这个方案对功能迭代非常友好， 后端如果修改了方法和返回结构， 只要重新生成 client ，前端 （如果是 ts ） 就能立刻感知类型和接口发生的变化。 在确定了 openapi 的方向之后，问题就简化成了，怎样才能方便地从多个数据源/数据库组合出来需要的数据？ 组合， 扩展 schema ， 通过申明的方式来构造数据 利用 orm 是一种手段， 但这个局限于数据库关联数据查询， 如果是跨多个服务的数据拼接， 常见的手段依然是手动循环拼接。 这个方面 graphql 做得很好，搭配 resolve 和 dataloader 可以轻松得组合出自己所需的数据结构。在 resolver 中， 数据源既可以是 orm 的返回值， 也可以是第三方接口调用的数据。 schema 申明了数据结构（接口定义），resolver 为所申明的数据结构提供真实数据（具体实现）。 dataloader 则提供了通用的解决 N+1 查询的方法。 按照上述的逻辑， 以 FastAPI pydantic 为例, 我们可以通过简单的继承来扩展已有的 schema ， 添加所需的关联数据 让 resolver 来负责数据的具体加载 class Sample1TeamDetail(tms.Team): sprints: list[Sample1SprintDetail] = [] def resolve_sprints(self, loader=LoaderDepend(spl.team_to_sprint_loader)): return loader.load(self.id) members: list[us.User] = [] def resolve_members(self, loader=LoaderDepend(ul.team_to_user_loader)): return loader.load(self.id) class Sample1SprintDetail(sps.Sprint): stories: list[Sample1StoryDetail] = [] def resolve_stories(self, loader=LoaderDepend(sl.sprint_to_story_loader)): return loader.load(self.id) class Sample1StoryDetail(ss.Story): tasks: list[Sample1TaskDetail] = [] def resolve_tasks(self, loader=LoaderDepend(tl.story_to_task_loader)): return loader.load(self.id) owner: Optional[us.User] = None def resolve_owner(self, loader=LoaderDepend(ul.user_batch_loader)): return loader.load(self.owner_id) class Sample1TaskDetail(ts.Task): user: Optional[us.User] = None def resolve_user(self, loader=LoaderDepend(ul.user_batch_loader)): return loader.load(self.owner_id) 在定义完了期望的多层 schema 之后，我们只需要提供 root 数据， 既 Team 的数据， 其他 sprint, story, task 的数据都会在 resolve 的过程中自动获取到。 借助 dataloader 这样的过程只会触发额外三次查询。 @route.get('/teams-with-detail', response_model=List[Sample1TeamDetail]) async def get_teams_with_detail(session: AsyncSession = Depends(db.get_session)): teams = await tmq.get_teams(session) teams = [Sample1TeamDetail.model_validate(t) for t in teams] teams = await Resolver().resolve(teams) return teams 在这样的模式下： service 层（后端）只需要提供 root 数据的查询， 和关联数据的 dataloader （ batch query)， 就能高枕无忧 controller 层（ BFF ）则只要对 schema 做简单的扩展， 并且调用合适的 dataloader ， 就能轻松得组合出期望的数据 https://github.com/allmonday/composition-oriented-development-pattern/blob/master/readme-cn.md 这个 demo 里面提供了多种组合模式的样例代码。 总结 为每个页面提供独立的 API ， 可以减少迭代中产生的问题。 也为接口优化提供了空间。 不复用 API ， 复用 service 。 通过继承扩展 schema ， 结合 resolver 模式， 可以在数据组合的效率上和 graphql 相媲美， 为每个页面构造独立的 API RESTFul 配合 openapi-ts 之类的 client 生成工具， 可以将方法和类型信息无缝传递给前端。 每个页面独立的 API, 概念类似每个页面有个独立的 render(page_name, data) 其他 这个想法的 python 实现：pydantic-resolve https://github.com/allmonday/pydantic-resolve 已经在我司 FastAPI 项目上稳定运行了一年多， 欢迎尝试。 这个模式在全栈的开发模式下的效率非常高， 自己定义好的接口， 一行命令 generate 就能在前端直接使用，特别清爽。 对比 graphql 省去了前端敲 query 的麻烦。 最近还在琢磨 typescript 下的实现，进度缓慢前进中。

太多站长建完站就把论坛放在一边，变成死坛，很大原因是不会运营。下面是我的一点经验，列表形式展现，相当于一个检查单。若能遵循这些做法，应该是个不错的社区 一定要确定论坛的主要话题，不要做大而全。只专注一个领域。 论坛刚起步先邀请制注册，种子用户决定了整个社区的氛围，对未来社区的发展起决定性作用。 最好有一个活跃的个人博客或大平台账号，方便引流。引流文不要用 GPT 生成，尽量简短真诚。 作为论坛站长要有编写内容的能力，初期的内容要靠站长编写。可以创建一些马甲号来促进活跃 做简中论坛，最好不要被墙，除非你的目标群体是程序员，否则请做好备案和审查。网站被墙后会损失大量流量，这是致命的。 做好心理准备吧，如果选择从邀请制转为开放注册，审查压力的巨大的。最痛苦的就是内容审核，很多有毒的东西。 不要靠资源下载引流，侵犯版权的同时，带来的用户也是伸手党。 定一个好规则，无需太长，能让用户有耐心完整阅读。可参考好好说话 大量有价值、对他人有帮助的帖子，是论坛壮大的关键，也可以给站长继续维护的信心。 最重要的是，要有足够的耐心。给社区至少两年的时间来发展，期间不断地打理它，才能壮大。然后盈利才是接下来该考虑的事，有流量就有一切。 如果对运营论坛暂时没有信心，可以从群博写起，召集几个志同道合的作者，写博客。等到一定规模，自然地就可以转变成一个论坛。知乎就是从一个群体博客开始的。

网络结构 光猫拨号，作为 DHCP server 直接下发 ip ，下发 ip 段为（ 192.168.1.2-192.168.1.200 ）。光猫 ip：192.168.1.1 路由器仅作为 AP 拓展无线。路由器 ip：192.168.1.4 一台矿渣装了 debian+docker 常开。debian ip：192.168.1.201 很简单的单层结构 谜之端口映射 原先用普通用户登陆光猫，增加端口映射，不生效；要到超级用户后，在维保页面增加端口映射，生效了。（外网端口 10001 ，映射 debian 的 22 端口） 一段时间后。超级用户登陆光猫 增加一个端口映射，外网端口 10002 ，内网端口（ 192.168.1.100:3389 ）。 这个映射死活不通。 删掉以前能够连通的端口后，再重新增加回这个端口，则这个端口也不通了。 结果就是：最早前增加的端口映射 通的，最近这两天新增的端口映射 不通。 已经重启过路由。 相关信息 运营商：杭州电信 光猫型号：ZNHG600 有公网 ipv4 ，且最早前增加的 10001 端口映射到 ssh 依然可联通。（现在就靠他用 ssh -L 转发= =）

现有阿里云深圳 ECS 主机一台，带公网 IPv4 IP ，准备自建 DERP 。 按网上的教程一路配下来： 域名搞定了，也实名了 DNS 搞定了 证书也搞定了（用 ACME+DNS API ） 防火墙里该放行的端口都放行了 该启动的也按教程启动了 到最后检验阶段，就是传说中的 “在浏览器中进入 https://IP:PORT ，如果看到以下网页则说明成功”，人家教程都能显示 “DERP This is a Tailscale DERP server” 的页面, 但我就显示“连接被拒绝”？？？？在路由器的 TailScale 里 netcheck 只能看到我的节点，但没有延时显示。 请问： 这是因为域名没有备案的原因吗？我 PORT 不走 443 走别的也不行。一脸懵逼。。。 自建 FRP 是不是比这个鬼 DERP 搭建要简单？

我应该去年发过一个帖子，主要讨论的是这几年一直在用公司配发的 Thinkpad 笔记本，不敢再将自己的笔记本带到公司去用。原因很简单，现在的企业监控软件实在是太厉害，比如深信服客户端，连微信聊天记录都能监控到，还有定时截屏等等功能 其实当时还有另外一个很重要的因素没说，那就是钱的问题。 现在大环境不好，我在我现在的公司呆了四年多了，也就从一个底层员工混到一个业务线研发负责人，最近三年时间里，部门就招了一个新人，没有人离职。 就业行情真的是太差了，四年多时间里，我自己曾经投过不少简历出去但就面试过两次，一次挂了一次嫌弃地方远没去，仔细说来也基本算没地方可以去了。然后在自己这家公司里，干了四年多，工资也只在去年涨了一千五而已。 现在的这个行情，我还能继续呆在现在的公司干几年，不好说，但我知道不管是职位还是工资，也基本是到头了。 因为现在大家都不愿意动，岗位非常的稳定，所以工资也就十分的稳定。甚至因为大环境导致市场缩水，公司这两年做项目也是十分的保守，前几年项目接到手软，我们加班也非常多，但是这两年项目就很稳定，做完这一个才做下一个，加班也很少了。就是这样稳定的情况下，我觉得自己再去投资一台高配电脑，提升自己的工作效率是一件不划算的事情。 当然了，我自己其实也是一个非常懒的人，下班回家再忙工作或者提升自己再或者自己接私活什么的，也是从来没有考虑的。年龄也大了，没有年轻时的那种冲劲，下班回家就想葛优瘫。 除了玩游戏就是刷视频看电影。所以我家里使用的电脑就是一台丐版 macmini,接电视当电视盒子用的。曾经还发帖说 8G 内存的 Mac 很好用结果被一堆人喷。 所以高配 Mac 对我来说基本就是毫无需求。 我还记得 14 年的时候，我斥资 9 千买下了人生第一台 MacBookpro ，2013late 款，坚信这是一笔非常划算的投资，如今高配 Mac 已然来到了 2 万价位，依然还有很多人在做着这样的投资。 å 2 万其实谁都能拿得出来，但是真正愿意做这种投资并且坚信是值得的，也算是一种本事吧，至少我现在没有这种本事了。

众所周知现在的趋势是面向 ai 编程了，本质上也就是人类已经可以用自然语言直接跟机器沟通了 看到有些大厂还在沉迷于研发新的编程语言，我觉得是有点陈腐了

现在是晚上九点，还没吃饭，所以行文可能有点乱。 大学学了两年，啥也没学会，只有各种语言的语法和机制略懂一二：c 、Java 、前端三件套。但是从来没独立写过正经的项目，哪怕是小玩具。 最近看到群里、站里很多人都喜欢给自己找需求写小玩具，但是我自己从来没想到写什么，可能是水平太差打从心底里害怕，从来都是：偶尔有一个想法->可能因为没有相关的知识储备一时想不到思路->放弃。 举个例子：我跟着 ytb 写了一个 react+node 的前后端博客，富文本用的 quill.js ，似乎不支持 markdown 和图片上传，博文是放在线上 mongodb 仓库，图片存在 firebase 上。 因为访问速度太差，想过把图片和博文放到本地 mongodb ，最好用 docker 放起来。博文还好，但是图片完全不知道怎么存，查了一下似乎有相关库，但是最后还是懒得动手，怕把写好的东西弄乱。 markdown 支持也是如此，大概知道 react 有 markdown 这个 npm 包，但是一时之间不知道怎么和富文本那个包结合起来于是就懒得动了。docker 的挂载卷也不知道怎么弄，最后也没有动手。整个项目直接放弃了（虽然写简历上了）。 今天看到站里有个台词图片生成器，觉得很有用也很好玩，很羡慕有动手能力。眼看着大三了周围的大佬大一大二就有实习/开源经历，感觉很没安全感。看过很多人的简历和面经都觉得很不可思议：哪里来的这么多有难点的项目和 idea ？ 现在觉得至少能给自己写点小玩具也很好了，大家写小项目的时候是什么过程呢？怎么来的 idea 和后续思路呢？有什么前置学习？

末流 211 ，java 选手 自己做了两个项目，第一个类似 one api 的那种 ai 聚合的项目，第二个是 一个简单的 ai 消息过滤通知。 投递准备得太晚了，6 月底才开始投的简历，截止目前面了 2 家， 第一家是 boss 上投的，一面比较轻松，二面好多没有答上来，感觉希望不大。 第二家是本地的公司，学校线下面的，问得比较基础，大部分能回答得上。 希望比上面一个大点，但不知道这种公司是不是单纯来完成考核的😮‍💨。 总结就是八股不熟，算法没怎么练。 最近牛客刷多了，感觉别人都要秋招了，我连实习都还没着落😭， 越来越焦虑了

难以想象，Go 语言这么火了吗？

求组 Google pixel 4a 插入英国的 esim 卡，无法开启谷歌地图的 Timeline 原生系统 开启 TW 的梯子 插入英国的 esim 卡 在手机上还是无法点击 Google 地图的那个 Timeline

我老婆卖的一款营养素保健品，在大陆没有销售，只能去香港买，也不能邮寄。 每次去香港，只能人肉背回来大概 1 万块钱的货。最近卖出去了七八万块钱的，有没有办法一次性弄到深圳呢？请有经验的大佬指导一下哈

做外包，最近遇到个异想天开的甲方，想预测彩票数字。该甲方自称潜心研究彩票 30 年，一直手算，现在觉得数据量太大了，想用程序实现。 虽然这个甲方在我看来是异想天开，但是他提出的计算规则倒是没有漏洞，我本着反正只谁出钱谁上帝的原则，实现了出来，但是现在遇到了性能问题。 他的算法并不复杂，首先，甲方提供了 75 个数字字符串，每个字符串都是 4 个数字，诸如 0123 3578 之类的。我在这里称其为样本数据。 彩票的开奖数字，每期都是 5 位数字，它的算法里，把这 5 位数字拆开成 5 个，每个单独去和 75 个样本数据进行计算。 一个样本字符串 + 开奖拆开的数字，会生成一系列值，这些值我接下来会有详述，这就是一行记录(每个生成的值是一列)。 因为有 75 个字符串，所以就有 75 行，于是，一个被拆开的数字，会生成一张表格，这张表格有 75 行。 又因为每期开奖数字是 5 位，所以每期彩票的开奖数字最后都会有 5 张表。 生成值（表格的列）有以下部分： A1：找上一期的开奖数字，计算上一期的开奖数字是否在对应行样本数据中出现过。 A2：当前开奖数字是否在样本数据中出现过？无论出现还是没出现状态，都从当前这期往之前的开奖记录回溯，如果状态和目前这期一致，就累加数值，直到出现一期和当前这一期不一样的状态，就终止(我大致看了一下平均遍历次数在 5 左右)。 Q15B：从当前期倒退 61 期，然后从此为起点遍历 30 期，只要这 30 期的开奖数字，命中了对应的样本数据，就+1 ，然后获得最终值。如果之前的期数不够，则该数据无效 Q15R：从当前期倒退 31 期，然后从此为起点遍历 30 期，只要这 30 期的开奖数字，命中了对应的样本数据，就+1 ，然后获得最终值。如果之前的期数不够，则该数据无效 P15B：从当前期倒退 16 期，然后从此为起点遍历 15 期，要要这 15 期的开奖数字，命中了对应的样本数据，就+1 ，然后获得最终值。如果之前的期数不够，则该数据无效。 P15R：从当前期倒退 31 期，然后从此为起点遍历 15 期，只要这 15 期的开奖数字，命中了对应的样本数据，就+1 ，然后获得最终值。如果之前的期数不够，则该数据无效， P15X：把前面的 A1 ，A2 ，Q15B Q15R P15B P15R 以一个简单的排列规则后得到的分类数。 Q15X：就是上一期的 P15X （也就是把上一期的 P15X 算一遍出来，所以如果之前期数不够，那么这个数据算不出来 C618：这是性能罪魁祸首，先不在这里算，问题在下面讲，先跳过。 就此你可以看到，这个过程从 A1 到 P15R 往前遍历了 1 + 5 + 30 +30 + 15 +15 = 96 次。然后为了算出 Q15X ，又来了一遍，所以遍历了 192 次。问题是，这仅仅是一行（因为是和一个样本字符串在对比），而这个表有 75 行，于是这个循环对比的过程执行了 75 x192 = 14400 然后我们每期开奖数字有 5 位，也就是说每期有 5 张这样的表，因此是 14400 x 5 = 72000 次。 这个代码我用的语言是 Java 。循环 72000 次，每一次几乎都进行了对比运算和累加运算，对比运算很简单用的是字符串查找 indexOf 方法。根据我反复测试，程序在预热完毕完毕后，执行上述计算花费时间是 45-50 毫秒。 45-50 毫秒也不算长啊。本来到这里还没太奇葩的，但是接下来甲方就有骚操作想法了。还记得前面写的那个 C618 吗？甲方的意思是，从目前的这期开奖记录开始，往前倒退 618 期，以此为起点，计算从此开始到当期为止（共 617 期）的从 A1 到 Q15X 的全部值。然后把这 617 的 A1 到 Q15X 和当前期的 A1 到 Q15X 按一定规则对比，比中了就累计值。 于是上面那计算一次要 45-50 毫秒的操作，要算 617 次。。。算一次 30 秒就过去了。。。 我想了很久，也没想到该怎么优化这个问题，这妥妥的是 CPU 密集型运算，但是它的算法规则不复杂，甚至可以说相当简单，除了向前追溯的次数太多了之外，整个运算过程几乎的规则就是对比和累计，对比的规则也就是要么查有没有，要么相等不相等。。。 我一度想看看那个 72000 次花费 45-50 毫秒的过程有没有优化的空间，但是看来看去也不知道该优化哪里。 目前我暂时不想考虑换语言之类的手段。 有没有算法大佬来聊聊这个场景该怎么办呢？

去年的时候看到一张关于 2023 年全球平均气温图表，然后找了下 这两年确实明显感觉到气温的不正常 这是平均气温，还有一些包括海洋气温、海平面上升数据我还没找 按照这种趋势之前所有的推测是不是都要推翻，什么 100 年淹没东京之类的。 有没有比较熟知这方面的大佬，能分享下一些其他的数据源和解读

各位师傅们好，我最近访问一些网站的时候发现很多的网站都貌似是出了 BUG 的状态 我想请教下为什么会有这种看起来是错误展示。 比如这是我在访问的一个网站，我打开之后这哥网页只有一个花括号 这是什么原因呢？ https://github.com/BreakALegCml/try/blob/main/Snipaste_2024-07-06_18-31-19.png 初次之外我还发现其他的一些网页是有其他的奇怪的显示，而不是正常的域名。为什么会有这种现象呢