DeepSearch

本文探讨了色温控制中 Mired 和 Kelvin 两种单位的区别、历史渊源，并科普了相关的色温知识，帮助读者理解它们在摄影和照明等领域的应用。

探讨物联网中灯的种类、分类及其技术特点，分析 DIM、CCT、RGB 等分类是否为协议及其背后的标准机构。

1 要干什么 今天在 macOS 上使用一个 Node.js 脚本通过 UDP 组播 (Multicast) 发现局域网内的智能网关设备。脚本大致逻辑是向组播地址 239.255.255.250 的 1900 端口发送发现指令，并监听本地端口等待设备响应。 在 Surge 未开启增强模式 (Enhanced Mode) 时，脚本工作正常。但一旦开启增强模式，即使 Surge 规则配置了局域网直连，脚本也无法收到任何设备的响应。同时，开启了 Surge 的 DHCP 功能。 2 探索过程 初步排查: 确认 Surge 规则中 FINAL,PROXY 或类似规则不会拦截局域网通信。 确认 macOS 防火墙允许 Node.js 或相应端口的入站连接。 尝试在脚本中将组播地址改为广播地址 (192.168.x.255)，发现可以工作，这暗示问题与组播的路由方式有关。 理解 Surge 增强模式: Surge 的增强模式会在 macOS 中创建一个虚拟网络接口 (TUN)，通常名为 utunX。 系统会将默认路由指向这个 TUN 接口，使得几乎所有的网络流量（除少数系统服务或特殊配置外）先经过 Surge 处理，再决定是走代理还是直连。 分析组播与 TUN 的冲突: UDP 组播依赖于网络接口加入特定的组播组 (client.addMembership(multicast_addr)) 以及从正确的接口发送组播包 (socket.send(..., multicast_addr))。 当增强模式开启时，由于默认路由指向 utunX，脚本： 发送组播包时，系统倾向于通过 utunX 发送，但 TUN 接口本身通常不适合直接处理物理局域网的组播。 监听并加入组播组时，可能也是在 utunX 接口上完成的，导致无法接收到来自物理网卡 (如 en0) 的组播包。 简单来说，流量被 Surge “劫持”到了 TUN 接口，但组播这种特殊的局域网通信方式在 TUN 接口上“迷路”了。 3 解决方案 核心思路是让发往组播地址的流量绕过 TUN 接口，直接通过物理网卡发送和接收。...

昨天读谷川俊太郎《一个人生活》，书中提到的「四块半榻榻米大小」引发了我的好奇。这究竟是多大？又有什么特别的含义呢？

其实还有一些，不过让我们开始第一弹的美化工作趴

为了可以更方便 Tailscale 穿透。

一个全面的指南，帮助开发者在 Cloudflare Pages 上使用 Hugo 构建一个 TIL（Today I Learned）博客，用于记录和发布每天学到的内容。