Mac 菜单栏多合一工具自荐：FancyTool
鉴于本人特别喜欢花里花哨的菜单栏，但又不想开机自启太多软件，所以自己开发了一个新的、轻量的，有点花里胡哨但又有些实用功能的多合一工具：[ FancyTool ]， 感兴趣的朋友可以点击链接下载使用。
我承认，这里的介绍是有点啰嗦😊
目前软件主要包含以下功能：
🚀 智能CPU动态图标
让性能可视化！
将任何GIF图片设置为你的菜单栏图标，它的播放速度会实时响应你的CPU使用率。
空闲时悠然自得，高负荷时急速狂飙，用最酷的方式监控系统状态。
支持完全自定义上传，打造你的专属动画！🌈 渐变彩色心情签名
用美丽的渐变色彩表达每日心情状态
完全可自定义的颜色和文字，展现独特个性
为您的菜单栏增添一抹艺术气息📋 高效剪切板管理
记录多次复制历史，随时找回需要的内容
智能分类整理，快速定位所需片段
支持文本、图片等多种格式，提高工作效率🖥️ 屏幕圆角美化
为Mac屏幕添加优雅圆角，提升视觉美感
智能适配多显示器设置，每块屏幕完美呈现
无性能影响的背景运行，细腻改善视觉体验📎 菜单栏折叠工具
自动整理拥挤的菜单栏图标，保持界面整洁
一键展开/折叠，平衡简洁与便捷
自定义排序和分组，完全按您的方式组织
技术特点
- 原生 Swift 开发，完美兼容最新系统
- 轻量级设计，资源占用极低
- 直观易用的界面，无需学习成本
- 定期更新，持续改进功能和体验
使用方法
赞赏
如果觉得有用，可以请我喝杯咖啡☕️
感谢以下老板投喂，🫰❤️
| 姓名 | 金额 | 时间 | 留言 |
|---|---|---|---|
| *龙 | ¥ 10.00 | 2025-08-27 15:00:00 | ☕️ |
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 M-finder！
相关推荐
2025-09-12
Mac 菜单栏多合一工具 FancyTool 更新啦！
本次更新聚焦「轻量体验」深度优化：不仅重构了 CPU 占用逻辑与系统唤醒机制，让后台运行更高效；更让动画交互全程保持丝滑流畅，资源消耗却低到近乎无感 —— 哪怕它常驻菜单栏，你也几乎察觉不到它的存在，既不拖慢系统，又能随时响应需求～ 下载地址： [ github ] [ gitee ] 目前软件主要包含以下功能： 🚀 智能CPU动态图标 让性能可视化 将任何GIF图片设置为你的菜单栏图标，它的播放速度会实时响应你的CPU使用率 空闲时悠然自得，高负荷时急速狂飙，用最酷的方式监控系统状态 支持完全自定义上传，打造你的专属动画 🌈 渐变彩色心情签名 用美丽的渐变色彩表达每日心情状态 完全可自定义的颜色和文字，展现独特个性 为您的菜单栏增添一抹艺术气息 📋 高效剪切板管理 记录多次复制历史，随时找回需要的内容 智能分类整理，快速定位所需片段 支持文本、图片等多种格式，提高工作效率 🖥️ 屏幕圆角美化 为Mac屏幕添加优雅圆角，提升视觉美感 智能适配多显示器设置，每块屏幕完美呈现 无性能影响的背景运行，细腻改善视觉体验 📎 菜单栏折叠工具 自动整理拥挤的菜单栏图标，保持界面整洁 一键展开/折叠，平衡简洁与便捷 自定义排序和分组，完全按您的方式组织 技术特点 原生 Swift 开发，完美兼容最新系统 轻量级设计，资源占用极低 直观易用的界面，无需学习成本 定期更新，持续改进功能和体验 如果有好的建议或者使用时遇到任何问题欢迎随时反馈👏
2025-01-24
系统异常崩溃实录
前言众所周不知，我在 24 年底入职了某连锁品牌的美甲公司，负责相关小程序和后台的开发与维护。 入职前了解到该项目最初由外包团队开发，并使用外包三件套：宝塔、TP、Mysql 进行部署和搭建，当时我心里就对它有了一个大概的印象，但是等我真正接手这个项目时，还是忍不住地两眼一黑，心头有一万头草泥马奔腾而过。 项目结构之混乱，方法定义之奇葩，没有一项不在挑战我认知的下限，我只能说，用屎山来形容这套代码都是在夸它，项目能平稳运行简直就是个奇迹。 哦，也不能算奇迹，因为这勾八玩意儿就没有一天是平稳的。 在告别了手动替换服务器代码并用 git 管理之后，我又先后经历了 CDN 欠费，小程序图片无法正常显示；SSL 证书过期，所有服务全部宕机；以及子项目域名过期却拿不到平台账号，最后只能换绑域名这样的种种混乱…… 在此之后，系统总算平稳运行了几天。 屎山的崩塌正当我撸起袖子，准备奋力重构这坨屎山时，年底到了，我又迎来了新一波的挑战。 1 月 16 号早上 10 点，我把手里刚开发完的小程序推送到正式版，之所以选在这个时间更新，是因为有些门店会营业到凌晨5点，10 前的使用量相对还少一些。 本来只是一个简单的更新操作，但是让我没想到的是，刚发版没一会儿，运营就突然在群里反馈说小程序卡，很卡，非常卡。 我被这消息搞得一头雾水，貌似刚才也没写 bug 吧？ 掏出手机操作一下，发现确实不能正常使用，阿西吧，赶紧联系同事撤回了版本。 这回总好了吧？掏出手机一看，还是不正常，群里也还在不停反馈依然无法登录等各种问题，傻眼的我更傻眼了。 打开服务器上的宝塔面板，两眼又是一黑，负载已经飙到了 100%，cpu 也到干了 94.5%。 wtf？这可是三台配置都不算低的服务器，按照上家公司的业务量，这个配置估计只需要一台就足够了。 我赶紧打开 nginx 的 access 日志，结果发现啥也没有，因为配置文件里压根儿就没有记录日志的代码。 再一问同事，之前服务器硬盘被日志塞爆过，没人清理，后来索性就都关了。 我无语凝噎。只能硬着头皮继续分析，发现负载和 cpu 飙升的原因是有几个 php-fpm 进程占用特别高。 它们在干啥？为什么会飙这么高？ 正当我们抓耳挠腮，掉了无数头发时，又在云服务器后台发现前一天 0 点也有同样的情况。 再往前一翻，清一色的 0 点和 10 点各项指标飞速飙升，0 点的飙升像座小山，10 点的飙升像座大山。 wō ní mǎ。 开始抓虫我慌了，开始怀疑起这个项目有异常的定时任务。 我的怀疑是有根据的，因为前一波开发的大聪明在调接口时，借助框架的事件驱动模块，用嵌套了两层的 http 接口调用一个所谓的 Task 接口，然后触发了 1000 多个 event…… 为什么要套两层接口，我不知道，为什么要这样写，我也不知道。 我只知道本地的接口被这玩意儿拖到了 6 秒一个请求，开发需求时我都是直接把这行代码注释的。 事情到了这个节骨眼上，我只能硬着头皮研究了一下这块代码，然后清除了里边 90% 左右的无用事件，然后又仔细检查了服务器的 crontab，emmm，就没有在 0 点和 10 点运行的任务。 查到这里事情还是没有大的进展，我的心态已经开始波动了，这屌系统崩就崩吧，这屌工作要不就干到今天算了吧？要不等过了年，我再出去找找其他工作？ 正当我想要打开 boss 直骗，给自己发昏的大脑来上一套强制冷却时，系统又诡异地恢复了平静。 我挠着头，一边感叹自己对这个屌系统的认知还是太过于浅薄，一边思考为什么会出现这样的局面，这里边还有没有什么其他值得怀疑的对象。 这时候，运营又在群里反馈了其他问题，我看这一波飙升已经过去，下一波也还很遥远，也就先放下了这件事，先去处理群里的其他问题。 时间一晃到了下午，闲下来的我和同事又发现数据库有很多慢 sql，其中一个最夸张的甚至运行了 126 秒。 是它吧？一定是，要不然还能是谁呢？ 我和同事马上开工，把系统里的慢 sql 都给优化了一遍，然后又给服务器装了 Atop 做监控，信心满满地等着 0 点时验证一波。 时间再次来到 0 点，服务器准时出现波动，但是只有 10 秒。 我先打开慢 sql 日志，完美，没有慢sql。再一看 Atop，10 分钟一次的记录完美避开的案发现场。 这样下去明天 10 点铁定得崩，那咋办？还有台闲置的服务器，加上去吧，看看后台，还有门店在使用系统，那只能等明天早上再加。 跟同事约好第二天早上 5 点半起来操作，我估摸这要不把 access 日志打开，看看涌进来的请求是不是都正常，因为这个时候已经开始怀疑是不是被人攻击了。 第二天一早，我们爬起来先把昨天推送失败的小程序再次更新，验证完之后又把新服务器加进了负载，忙完以后定了个 9 点多的闹铃，然后赶紧躺下又眯了一会儿。 不到 10 点，又被群里的消息吵醒，看完发现是前一天优化的 一条 sql 有问题，没有正常生成数据，快 10 点了，我们把问题先丢在一边，先盯着监控看服务器状态。 结果很快再次打脸，新增的服务器虽然也扛住了很多并发，但系统还是崩了，大量用户无法排队，大量门店也无法叫号，这次挣扎再次以失败告终。 我把 access 日志拉了出来，逐行分析了上千行日志，发现事情并没有那么简单，这些请求似乎都很正常，难道攻击我们的还是个高手，伪装成了正常用户？ 我统计了每个接口的访问数量，又统计了每个 token 访问的接口数量，还解析了几个用户的 token。但是，这些东西还是没有任何帮助，我没有找到任何被攻击的证据。 事情再一次陷入僵局。 令人无语的真相时间再次来到 0 点，我们提前停下了所有定时任务，系统不出所料，还是全线飘红，不过我们好在知道了问题的根源是在数据库。 但是为什么会在 0 点和 10 点这两个时间涌入大量的请求，我们还是怀疑是不是有人在攻击我们，苦于没有证据，只能继续分析日志。 我们发现在 0 点的一瞬间，系统涌入大量的排队操作，其他调查均无成效的情况下，我们只能统计了 0 点后每家门店的排队情况，打算第二天联系门店核实一下这些排队是否真实，同事也把我们统计的表格发给了老板。 每个人的心头都像压了一座大山，怎么办，再不搞定这个年还能过好吗？ 第二天浑浑噩噩地爬起床，灌下一杯超浓咖啡，我带着深深的忧虑再次上班。 路上，同事发来一张聊天截图，老板说，这些是正常的，很多门店就是 0 点开始放号，因为每个门店的排号是有限的，顾客只能在放号的一瞬间去抢，包括十点也是一样的情况。 我觉得天塌了，忍不住骂一声他喵的，合着我们起早贪黑辛苦调查，最后调查了个寂寞，系统宕机纯粹就是因为瞬时并发太大？？？ wtf！这个世界是真的魔幻啊，做个美甲还要 0 点起来抢号？ 波折的解决之路时间一晃又到 0 点，我们白天把排队叫号相关的接口逐个优化，该加缓存的也都加上了缓存，同事也研究起数据库的从库和代理，等着 0 点验证一下能否扛住压力。 然后，我们卡在了第一步，读库连不上去，服务器方面，靠着手动切换负载，硬是扛住了这一波。 再一看日志，排号接口平均在 20 毫秒，叫号接口平均在 250 毫秒，但是读库的内存才使用了 17%，像极了你那个出工不出力天天在摸鱼的老油条同事。 阿西吧，这可不行。 读库可是按小时收费的，扛过了零点高峰，我们马上下了，准备第二天早上继续研究。 第二天一早又把读库配好，也让运营通知了门店错峰放号，我紧盯着监控，准备随时切换负载分配，同事那边也在联系服务器客服，让他们远程协助，解决读库不发力的问题。 但是很遗憾，10 点前读库的问题还是没能解决，服务器小崩了一下。 时间已经到了周日，距离放假还有一周，距离第一次触发这种情况已经过去一周还要多，再不解决，真就过不好这个年了呗。 虽然这是个从系统诞生就已经存在的问题，但在业务高峰期频繁触发实在打脸，老板拉我们开了个会，说以前的人是把服务器的流量降下来，听得我们目瞪狗呆，这是什么傻逼骚操作？降流量，咋不把服务关了呢。 一番拉扯后，我们决定给接口限流，10-10:30 期间，每分钟放出 100 个排号，超出就等下一波。 方法测完上线后，我们终于迎来了第一个好消息，读库能连上了。 当即选了一台服务器切了过去，然后进行了一波测试，发现读库还是有点慢，有点鸡肋。 同事再次提了工单，在对方的大力协助下，我们升级了读库和代理的配置，几乎是在一瞬间，主库的 cpu 睡着了。 0 点后，qps 一路狂飙到了 18000/s，服务器的负载虽然又到了 100%，但是 cpu 一直维持在 80% 左右，这件事总算成了。 我特么能睡个好觉了……
2021-04-13
一句话看懂集群、微服务和分布式的区别
一个完整的服务拆分成多个微小的服务，就是微服务。 每个服务不止一个就是集群。 微服务部署在多台服务器上，服务器之间可以相互通信就是分布式。 微服务与分布式的细微差别是微服务可以部署在一台服务器，也可以部署在多台服务器。
2024-03-03
职业生涯知识回顾-关于抽象类和接口的思考
抽象类和接口是两个很容易产生疑惑的概念，分不清它们的使用场景，其实只要记住两点就比较好理解： 接口是对行为的抽象 抽象类是对子类有哪些属性和行为的抽象 当你需要对一个类有哪些行为进行约束时，使用接口；需要为其他类提供一个模板以及一些通用的属性和行为，使用抽象类。 在理解什么是抽象类和接口的前提下，延伸出一些思考：在一定程度上，接口似乎是比抽象类更底层的存在，是否可以理解为先有行为，对行为进行组合才能有类？ 那么下面代码中，抽象类对接口的实现有没有实际意义？ 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061<?phpinterface IAnimal{ public function move(): void; public function sleep(): void; public function eat(): void;}interface Wag{ public function wag();}interface Climb{ public function climb();}abstract class AbstractAnimal implements IAnimal{ abstract function move(): void; public function sleep(): void { echo 'sleeping', PHP_EOL; } public function eat(): void { echo 'eating', PHP_EOL; }}class Dog extends AbstractAnimal implements Wag{ function move(): void { echo 'dog running', PHP_EOL; } public function wag(): void { echo 'wagging', PHP_EOL; }}class Cat extends AbstractAnimal implements Climb{ function move(): void { echo 'cat walking quietly', PHP_EOL; } public function climb(): void { echo 'climbing', PHP_EOL; }} 如果更进一步，抽象类的方法和接口相同，并且都是抽象方法的情况下，接口和抽象类谁更有存在的意义？ 抽象类是为了提高代码复用，定义类之间的层次关系，接口是为了实现多态性和解耦。我们要知道两者并不是对立关系，甚至目标一致，都是为了提高代码质量。 工具是死的，但人是活的，所以我认为使用者并不用太过于纠结，代码没有百分百完美，也不是死板的教条。只要在需求和设计目标明确的前提下，选择抽象类或接口，甚至组合起来使用都是可以的，解决实际问题才是我们最终的目的…… 最后，再来回答一下前边的三个问题： 抽象类和接口的层级关系：抽象类可以被视为介于接口和类之间的一种中间形式。 抽象类实现接口的意义：统一接口规范，确保抽象类和子类都遵循接口的约束。 全抽象方法的抽象类和接口谁更有意义：如果只是定义方法契约而不提供具体实现，接口更有意义；抽象类有明确扩展目标时，保留抽象类。
2024-03-01
Laravel Octane 和 Swoole 协程的使用分析二
又仔细研究了下 Octane 源码和 Swoole 的文档，关于前几天 Laravel Octane 和 Swoole 协程的使用分析中的猜想，得到进一步验证： Swoole 的 HTTP Server 启动后会创建一个 master 进程和一个 manager 进程；master 进程又会创建多个 reactor 线程，负责将请求转发到 work，并从 work 接收结果发送给客户端，相当于 nginx；manager 会创建多个 work 和 task 子进程，work 进程相当于 php-fpm，task 专门处理一些耗时任务，最后将结果交给 work； 而 LaravelOctane 的 concurrently 方法，其实是以 task 为基础，也就解释了为什么脱离 HTTP server 会无法使用。 Swoole
2024-09-19
Mac 用 Brew 安装旧版本 PHP
最近又用到 php7.4，奈何本地早就已经升到了 8，想搞回来，发现一个简单好用爽歪歪的三方库，需要的可以试一下，5.6 - 8.4 都有。[ homebrew-php ] 添加地址库1brew tap shivammathur/php 安装指定版本1brew install shivammathur/php/php@7.4 切换版本12345brew services stop php@7.4brew unlink php@xxbrew link php@7.4brew services start php@7.4 搞定收工。