macOS磁盘空间不释放(删除文件空间不恢复)

昨天(2025/12/15)把手上的 MacBook Pro M2 版本的系统升级到 macOS Tahoe 26.2 版本之后,发现系统剩余空间只有不到 50GB了,于是手工删除可一些不重要的文件,大约 200GB 的样子。

结果情况不仅没有好转,反倒是更严重了。更匪夷所思的是,文件删除的越多,系统剩余可用空间越少。最后急剧减少到接近为 0, 系统报错存储空间不足,内存不足。

怀疑是 TimeMachine 导致的问题,于是尝试了

也是不起任何作用,其中的一个镜像无论如何都删除不了。

最后发现是 Apple FS 的快照空间占用了这部分空间,很奇怪以前没有发生过类似情况。

怀疑是系统升级设置了回滚快照,防止升级出现问题。

但是系统升级完成后,快照逻辑没有被解除,导致文件越删除磁盘空间越少的诡异问题。

我这边操作删除的时候,这部分快照消耗了大约 400GB 的磁盘空间,删除快照之后,系统卡顿了大约几分钟的样子恢复正常。应该是系统在进行集中磁盘清理导致的锁盘引起卡顿。

  1. 打开"磁盘工具"
  2. 点工具栏的显示-显示APFS快照(或者按键盘command+shift+s)
  3. 下放会出现快照占用空间

参考链接


Mac OS 磁盘空间不释放(删除文件空间不恢复)

Flutter Uint8List to Pointer

参考链接


flutter Uint8List to Pointer<Uint8>

‘withUnsafeBytes’ is deprecated: use ‘withUnsafeBytes(_: (UnsafeRawBufferPointer) throws -> R) rethrows -> R’ instead

在编写 Swift 代码的时候,执行如下代码的时候:

出现如下警告:

修正警告的方式,参考使用如下代码:

参考链接


Flutter调试Linux平台代码(VSCode)

Flutter 开发过程中,需要编写调试 Linux 平台相关的代码,下面介绍一下使用 VSCode 进行调试的相关配置。

在工程根目录下的 launch.json 中增加如下配置:

注意 "program": "${workspaceFolder}/build/linux/arm64/debug/bundle/MyApp", // Path to your compiled Flutter Linux executable 根据项目的实际情况进行配置,主要需要修改的地方就是路径中的 arm64 或者 x64 以及最后的应用名。

完整的配置如下:

调试的时候,参考下图进行选择,选择的配置项目就是 "name": "Debug native",如下图:

参考链接


西门子洗碗机SN23E831TI排水泵故障维修

最近家里的西门子洗碗机不工作了,故障表现就是洗碗不结束,面板上的进水龙头指示灯闪烁,永远不结束。仔细观察,触摸洗碗机,会发现洗碗机外部凉凉的,不加热。洗碗中途打开柜门,里面没有温度。只要没有温度,大概率故障原因就是加热模块损坏。

继续阅读西门子洗碗机SN23E831TI排水泵故障维修

访问github.com被解析到127.0.0.1问题解决

最近访问 github,发现总是访问失败。经过排查后确认问题原因是 DNS 解析被污染导致 github.com 被解析到 127.0.0.1 导致的。

如下图:

解决方案:

1、指定DNS为其他知名DNS服务器:如1.1.1.1,8.8.8.8, 114.114.114.114等;

2、添加hosts文件记录,将github的ip地址增加进去。

参考链接


H3CBook Pro 14 G2合盖睡眠导致指纹解锁不可用M2硬盘丢失问题

公司新发的 H3CBook Pro 14 G2 使用了 Intel i7 1360P 当前 BIOS 版本号 F.11 版本日期 12/27/2024 。机器自带内存 16GB,感觉不大够用。到手之后,买了一个新的 32GB DDR5 内存,顺手插上了老电脑上替换下来的一个 Intel M2 固态硬盘。默认情况下合盖会进入自动睡眠状态。重新打开盖子,指纹解锁不可用,进入系统之后,新增的 M2 硬盘丢失。重启系统后可以恢复。

跟客服也沟通了一下,目前暂时没有新的 BIOS 版本发布。目前的解决方案就是在 Windows 11 的电源设置里面关闭合盖 “睡眠” 选项,全部设置为 “休眠”。

OpenGrok升级到1.14.4版本后在首页报错 "Method not found: class org.opengrok.web.PageConfig.getRelativePath"

OpenGrok升级到1.14.4版本后,在首页报错,如下:

继续阅读OpenGrok升级到1.14.4版本后在首页报错 "Method not found: class org.opengrok.web.PageConfig.getRelativePath"

API 版本迭代,怎么进行 API 多版本处理?

API 版本迭代是在软件开发过程中非常常见的一种需求,尤其对于 Web API 来说,随着业务需求的不断变化和技术的发展,API 的版本迭代变得愈发重要。API 版本迭代的目的是为了满足不断变化的业务需求、修复缺陷和改进功能,同时保持向后兼容性。然而,随着多个版本的 API 共存,如何进行多版本处理成为了必不可少的问题。

为什么需要进行版本迭代?
  1. 向后兼容性:在引入新功能或修改现有功能的同时,应该尽可能保持与现有版本的 API 的兼容,避免对已有客户端和应用程序的影响。
  2. 兼容性测试:为了确保新版本 API 的稳定性,需要进行兼容性测试。可以通过多版本处理来降低测试的成本和风险。
  3. 用户体验:通过多版本处理来提供更好的用户体验,向用户和开发者提供更多的选择和灵活性,使其能够逐步升级到新版本而不会影响其业务。
    因此,API 多版本处理对于确保系统的稳定性、提高开发效率和用户体验至关重要。
常见的 API 迭代模式

API 版本迭代需要进行版本控制,以便开发者和用户能清晰地了解各个版本之间的差异和兼容性情况。常见的 API 版本迭代模式包括语义版本控制(Semantic Versioning),它是一种广泛应用于软件开发领域的版本号命名规范。

语义版本控制将版本号分为主版本号、次版本号和修订号三个部分,分别代表了不同层次的变化:

  • 主版本号:当你做了不兼容的 API 修改时,需要升级主版本号。
  • 次版本号:当你做了向下兼容的功能性新增时,需要升级次版本号。
  • 修订号:当你做了向下兼容的问题修正时,需要升级修订号。
    语义版本控制的优点在于,通过版本号的规范化命名,能够清晰地表达版本之间的关系和变化。开发者和用户可以根据版本号了解这个版本带来了什么样的变化,以及对其现有应用的影响。这有助于提高版本变更的可预测性和透明度。

多版本处理的挑战

多版本处理是 API 设计中常见的问题之一。当 API 需要支持多个版本时,可能会遇到以下挑战:

  • 兼容性:不同版本的 API 可能存在不兼容的情况,导致客户端无法访问或使用所需版本的 API。
  • 功能冲突:不同版本的 API 可能包含不同的功能,导致客户端在使用不同版本的 API 时遇到功能冲突。
  • 对用户的影响:API 版本的变化可能会对用户的使用体验产生影响,例如用户需要升级客户端软件或重新学习如何使用 API。
  • 对开发者的影响:API 版本的变化可能会给开发者带来额外的开发和维护工作,例如开发者需要维护多个版本的 API 文档和代码库。
解决方案一:URI 版本控制

URI 版本控制是一种通过在 API 的 URI 中包含版本号来区分不同版本的 API 的方法。这种方法简单易懂,并且支持大部分客户端工具。

解决方案 URI 版本控制
概念 API 版本作为 URI 的一部分,如/api/v1/users表示第一个版本,/api/v2/users表示第二个版本。客户端通过在请求中指定 URI 版本号选择 API 版本。
优点
简单易懂:概念直观,易于理解。
  广泛支持:得到大部分客户端工具支持,包括浏览器、HTTP 客户端库和 RESTful API 框架。
  独立部署:不同 API 版本可独立部署,有利于开发和维护。
缺点 冗长:每个 URI 中包含版本号导致 URI 冗长。
  版本冲突:存在不同 API 版本时可能发生冲突,导致客户端无法访问所需版本。
  难以发现:URI 中包含版本号可能使客户端难以发现新 API 版本。
适用场景 API 版本较少且不经常更新。
  客户端工具支持 URI 版本控制。
  API 需要与多种客户端工具兼容。
解决方案二:标头版本控制

标头版本控制是一种通过在请求头中包含版本号来区分不同版本的 API 的方法。这种方法与 URI 版本控制相似,但更加灵活,并且可以支持更多类型的客户端工具。

解决方案 标头版本控制
概念 API 版本作为请求头的一部分,例如,使用Accept: application/json; version=2表示客户端请求使用 API 的第二个版本。服务器根据请求头中的版本号选择 API 版本。
优点 灵活:更加灵活,支持多种客户端工具,包括浏览器、HTTP 客户端库和 RESTful API 框架。
  版本独立:与 URI 无关,不同 API 版本可以在同一个 URI 上部署。
  易于发现:通过请求头可以发现新的 API 版本。
缺点 复杂性:概念较复杂,可能需要客户端工具特殊处理。
  兼容性:需要客户端工具支持,否则无法使用。
  性能:可能影响性能,因为服务器需要额外处理请求头。
适用场景 API 版本较多且经常更新。
 
客户端工具支持标头版本控制。
  API 需要与多种类型的客户端工具兼容。
解决方案三:内容协商

内容协商是一种根据客户端的需求动态选择合适的 API 版本的机制。这种机制允许客户端在请求中指定它支持的 API 版本,然后服务器根据客户端支持的版本选择要使用的 API 版本。

解决方案 内容协商
概念 根据客户端需求动态选择合适的 API 版本,通过 HTTP 协议中的Accept和Content-Type请求头指定客户端支持的版本和内容类型。服务器根据请求头信息选择 API 版本和内容类型。
优点 动态选择:允许客户端动态选择合适的 API 版本,更容易适应客户端需求。
  兼容性:允许客户端使用不同的 API 版本,提高 API 兼容性。
  性能:提高性能,服务器可以根据客户端需求选择最合适的 API 版本和内容类型。
缺点 复杂性:概念较复杂,需要客户端工具和服务器特殊处理。
  兼容性:需要客户端工具和服务器都支持内容协商,否则无法使用。
适用场景 API 版本较多且经常更新。
  客户端工具和服务器都支持内容协商。
  API 需要与多种类型的客户端工具兼容。
通过 Apifox 进行版本控制

Apifox 是一个集接口文档、API 调试、自动化测试、Mock 服务等功能于一体的综合 API 开发协作工具。Apifox = Postman + Swagger + Mock + JMeter,Apifox 支持调试 http(s)、WebSocket、Socket、gRPC、Dubbo 等协议的接口,并且集成了 IDEA 插件

原始链接


API 版本迭代,怎么进行 API 多版本处理?

macOS 26 系统如何在聚焦搜索中不显示 iPhone App

在 macOS 26 系统中,Apple 增强了「聚焦搜索」(Spotlight)的功能。如果你启用了 iPhone 镜像,系统会自动将 iPhone 上的应用程序同步到 Mac 的聚焦搜索结果中,方便直接在 Mac 上快速启动或查找。

如下图:

继续阅读macOS 26 系统如何在聚焦搜索中不显示 iPhone App