Jekyll2026-03-31T13:33:58+08:00https://luis-ai-systems.github.io/feed.xmlLuis Li技术，生活Luis Li构建纯静态前沿交互：基于 Canvas 的绝对避让排版引擎2026-03-31T00:00:00+08:002026-03-31T00:00:00+08:00https://luis-ai-systems.github.io/2026/03/31/build-canvas-physics-engine为了将博客的极简赛博风贯彻到底，我在这两天实现了一个非常有实验性的页面——“次元（Absolute Terror Field）”。

灵感来源于 Chenglou/Pretext 震撼的排版避让效果，但与之不同的是，我们没有引入庞大的 React 生态或外网后端。我仅仅通过 原生 HTML5 <canvas> 和百行的纯 JavaScript 物理弹簧算法，就在静态博客中复现了满屏字母的引力场效果。

Ⅰ. 核心技术痛点解析

构建这套纯前端交互矩阵涉及到了多个底层问题：

  1. 真实物理模拟与碰撞检测：字符不仅要躲开我们的光标/节点，离开后还要像挂着弹簧一样优雅地“崩”回原位。
  2. 主题同步 (Theme Awareness)：传统的 <canvas> 绘图是静态像素，无法跟随博客左上角的“月亮/太阳”白天黑夜模式自动变色。
  3. MacBook 触控板事件劫持：苹果 Safari 或 Chrome 中的触控板惯性拖拽容易被识别为滚动而打断物理坐标采集。
  4. 代码压缩引擎的“静默暗杀”：由于博客应用了 HTML 代码压缩机制，一段无害的 “//” 注释引发了长达半天的黑屏惨案（后文详述）。

Ⅱ. 物理引擎运转架构

为了彻底搞清这个循环结构，我梳理了整个引擎渲染和处理的管线（Pipeline）。

graph TD
    A["Window resize / boot"] --> B("初始化 Canvas 尺寸、Nodes 与 Particles")
    B --> C{"requestAnimationFrame"}
    
    %% Input Layer
    subgraph 交互监听层
        I1("mousedown / touchstart") --> |捕获高亮节点| I2("修改节点坐标及 isDragging 属性")
        I3("mousemove / touchmove") --> |刷新绝对坐标| I2
    end
    
    %% Physics Calc
    subgraph 物理运算帧
        P1("遍历 Particles") --> |计算与基底距离| P2("施加恢复拉力 vx = vx + dx * 0.08")
        P2 --> P3("计算与 Nodes 距离矩阵")
        P3 --> |若 Dist < Radius| P4("施加弹斥力 Mathf.atan2 计算夹角推开距")
        P4 --> P5("速度附加快衰减 vx = vx * 0.7 降噪避免乱飞")
        P5 --> P6("更新字符最新坐标 x, y")
    end
    
    %% Render Pipeline
    subgraph 像素绘制管线
        R1["读取根节点主题状态"] --> R2["清理上一帧 clearRect"]
        R2 --> R3["重绘动态底色 fillRect"]
        R3 --> R4["绘制二次贝塞尔曲线连结 (跳线)"]
        R4 --> R5["根据物理运算层坐标重绘所有字体"]
        R5 --> R6["绘制 Nodes 与发光滤镜 shadowBlur"]
    end

    C --> |读取| I2
    C --> P1
    P6 --> R1
    R6 --> C

Ⅲ. 血泪踩坑指南

在实现这套机制时，除了算法上的调整，这三个堪称隐形杀手的坑耗费了最多时间：

1. Jekyll compress HTML 压缩器与 JavaScript 的量子纠缠

在这个系统中，最离谱的 Bug 就是——页面在本地开发正常，一旦推送到 GitHub Action 部署后，整个 Canvas 画面只剩下一片纯黑幕布，代码抛出完全隐藏的闪退。

最终发现问题的核心竟是： 博客为了性能使用了 {% layout compress %} 模块来极度压缩 HTML 代码。它会在构建时粗暴地删掉 HTML 里的所有换行符（Newline）。 这导致我在 <script> 里的 // 计算反向推力 等单行注释，因为失去了“换行”保护，硬生生地把 // 后面长达几百行的核心 Javascript 全部当成了注释给吃掉了，直接引发严重词法 SyntaxError。

修复方案： 必须在静态博客的直接内联脚本中强制放弃 // 单行注释，严格采用 /* Block 注释 */ 以防被压缩器吞断语境。

2. Mac 触控板拖拽与视口滚动

原本仅绑定了 mousemove，发现 Mac 触控板点按拖拽时常常失灵。 这是因为触控板微小的移动经常被浏览器判定位系统级别 Scroll 而阻止事件。解决方案必须两路齐发：

  1. CSS 钳制：为 Canvas 对象加上 touch-action: none !important; 彻底禁用所有的手势。
  2. 主动拦截：在 JS 监听事件中，加入 if (e.cancelable) e.preventDefault(); 拒绝原始滚轮和上滑操作，抢夺坐标归属权。
  3. 扩大点击域：将节点抓取判断放宽到了勾股定理距离求交的 dx*dx + dy*dy < 2500（50px 半径范围），让触控板不再需要肉眼追踪 1 个特定细微像素。

3. 主题（Theme Awareness）的解耦跟随

Canvas 原生是不讲 CSS color: red 道理的，它只读十六进制。为了能随着用户手头的“白昼/暗夜”模式实时切换效果。我们巧妙地使用 JS 将检测逻辑融入了 60fps 的 animate() 循环中：

function isLightTheme() {
    return document.documentElement.classList.contains('light-theme');
}

每一帧都会嗅探博客是否注入了发白的主题雷达，随后智能重配文字为 “墨水蓝/赛博紫外”。至此，一套不需要 React，不需要后端计算，甚至不需要外部 NPM 包的高能静态实验室绝对领域落地了！

快去上方导航栏体验 [次元] 的自动排版威力吧！

]]>Luis Li终极解决暗黑模式闪烁 (FOUC)：硬核内联 CSS 方案2026-03-30T20:30:00+08:002026-03-30T20:30:00+08:00https://luis-ai-systems.github.io/2026/03/30/fix-fouc-theme在给博客加上了极其酷炫的赛博朋克深色/浅色主题切换后，我遇到了一个前端老生常谈、但极其恶心的问题：FOUC (Flash of Unstyled Content)。

具体表现为：当我把主题切到“浅色模式”，然后点击导航栏去别的页面时，页面总是会极快地闪过一下深色背景，然后再变回浅色。这极其破坏那种极致冷酷的极客体验。

本文记录了我是如何一步步排查，并最终用“内联关键 CSS”将其彻底歼灭的过程。

为什么会闪烁？

刚开始，我的主题检测脚本写在 main.js 里：

  1. 浏览器加载 HTML
  2. 浏览器加载并解析 premium.css（里面包含了 body 默认的 #050508 深色背景）
  3. 浏览器渲染：此时页面是深色的
  4. main.js 被执行，读取 localStorage
  5. 发现用户选了浅色，于是给 body 加上 .light-theme class
  6. CSS 重新计算：页面跳变回浅色

这中间哪怕只有 50 毫秒的时间差，人眼也能明显捕捉到刺眼的“深色闪烁”。

第一次尝试：前置检测脚本（失败）

网上的标准解法是将 <script> 移到 <head> 中阻塞执行，在 <body> 渲染前给 <html> 加上主题 class。

<head>
    <script>
      if (localStorage.getItem('theme') === 'light') {
        document.documentElement.classList.add('light-theme');
      }
    </script>
</head>

结果：依然闪烁。

这是因为外部 CSS 文件的加载是异步阻塞的。虽然 <html> 在第一时间拿到了 .light-theme 标记，但由于 html.light-theme { background: #fff; } 的规则写在 premium.css 里，浏览器必须等这个外部文件下载完才能应用。而在下载期间，默认的深色背景再次霸占了屏幕。

终极方案：内联关键 CSS (Critical CSS)

要做到绝对的零延迟，唯一的办法是：让浏览器在解析到 <head> 的瞬间，不需要发任何网络请求，就拥有渲染浅色背景的全部 CSS 素材。

我们在 <head> 中用 <style> 标签硬编码了导致页面大面积闪烁的关键像素规则：

<head>
    <!-- 1. 阻塞式读取判定 -->
    <script>
      if (localStorage.getItem('theme') === 'light') {
        document.documentElement.classList.add('light-theme');
      }
    </script>

    <!-- 2. 核心覆写规则直接内联 -->
    <style>
      /* 只要 html 有了 light-theme，立刻覆盖根变量 */
      html.light-theme {
        background: #f8f9fc !important;
        --color-bg-deep: #f8f9fc;
        --color-text-primary: #1a1a2e;
        /* ... 其他核心变量 */
      }
      
      /* 强行杀死深色的网格动画层 */
      html.light-theme body::before {
        animation: none !important;
        background: none !important;
      }
    </style>
</head>

渲染流水线对比

下面这张 Mermaid 架构图清晰地展示了优化前后的浏览器渲染流水线差异。你可以看到优化后，浅色背景在 First Paint (首次绘制) 就已经就位了。

sequenceDiagram
    participant Browser as 浏览器
    participant Head as <head> 解析
    participant CSS as 外部 CSS 网络请求
    participant Body as <body> 渲染
    participant JS as 外部 JS 执行

    rect rgb(40, 40, 50)
        Note right of Browser: 【优化前】发生闪烁
        Browser->>Head: 解析开始
        Head->>CSS: 发起 premium.css 请求
        Browser->>Body: 开始渲染 (First Paint)
        Note over Browser,Body: ⚠️ 使用默认深色变量渲染<br>此时用户看到深黑色！
        CSS-->>Browser: 返回深色+浅色样式表
        Browser->>JS: 发起 main.js 请求
        JS-->>Browser: 执行脚本读 localStorage
        JS->>Body: 添加 .light-theme class
        Note over Browser,Body: 🔄 重新计算样式并重绘<br>画面突变为浅色 (闪烁发生) 
    end

    rect rgb(20, 50, 40)
        Note right of Browser: 【优化后】完美顺滑
        Browser->>Head: 解析开始
        Note over Head: 执行内联 <script>
        Head->>Head: 发现浅色，给 <html> 加 class
        Note over Head: 解析内联 <style> (Critical CSS)
        Head->>CSS: 发起 premium.css 请求
        Browser->>Body: 开始渲染 (First Paint)
        Note over Browser,Body: ✅ 命中内联规则 html.light-theme<br>首次绘制即为完美的浅色背景！
        CSS-->>Browser: 返回剩余样式
        Browser->>JS: 发起 main.js 继续绑定事件
    end

总结

对付主题闪烁（FOUC），不仅要阻止渲染（Blocking Script），还要解决CSS 同步阻塞（Critical CSS）。

把第一帧必须显示的背景颜色、主题变量、甚至伪动画的开关，全部剥离出来，硬写在 <head> 的 HTML 源码里。只有丢掉对外部网络资源的依赖，才能换来真正的丝滑切换体验。

]]>Luis Li从零开始的数字虚空探险2026-03-24T10:00:00+08:002026-03-24T10:00:00+08:00https://luis-ai-systems.github.io/2026/03/24/websocket欢迎来到我的全新结界。经过了数次的重构与设计，这里终于拥有了我理想中的黑客与二次元交织的极致冷酷感。

序章

在这个数字化的虚空世界中，每一个比特都承载着我的意志。在这里，你可能会看到关于编程魔法的代码片段，也可能是某个午后对一部冷门番剧的碎碎念。

def cast_magic():
    print("Hello, Digital World!")
    return True

保持优雅，保持好奇。

WebSocket 架构图 (WebSocket Architecture)

本文档描述了 Workflow Engine 项目中 WebSocket 实时消息系统的整体架构设计，包含前端连接管理、后端处理逻辑、鉴权流程及消息持久化机制。

1. 整体架构图

graph TD
    subgraph FE["前端 - Vue3 Client"]
        WSNB["WebSocketNotificationBell.vue"] --> WSM["WebSocketManager.js"]
        WSM -->|"1. 建立连接"| WS_NATIVE["Native WebSocket"]
        WSM -->|"2. 发送消息/心跳"| WS_NATIVE
        WS_NATIVE -->|"3. 接收实时消息"| WSM
        WSM -->|"4. 分发消息"| WSNB
        WSNB -->|"REST API"| API_GATEWAY["Spring Boot REST Controllers"]
    end

    subgraph BE["后端 - Spring Boot Server"]
        WS_NATIVE <-->|"WebSocket ws://"| WS_CONFIG["WebSocketConfig"]
        WS_CONFIG --> HSI["ChatHandshakeInterceptor"]
        HSI --> ST["Sa-Token Auth"]
        ST -->|"UID"| WS_CONFIG

        WS_CONFIG --> CWH["ChatWebSocketHandler"]

        subgraph MSG["消息处理逻辑"]
            CWH -->|"异步执行"| TE["TaskExecutors"]
            TE -->|"私聊/群聊"| PMG["Private/Group Message Logic"]
            TE -->|"离线消息"| OM["Offline Message Logic"]
            TE -->|"ACK确认"| ACK["Message ACK Logic"]
        end

        subgraph STORE["存储与缓存"]
            PMG --> DB_MSG[("MySQL: chat_message")]
            OM --> DB_OFFLINE[("MySQL: chat_offline_message")]
            PMG --> CACHE_GROUP["Group Member Cache"]
        end

        CWH -->|"Session管理"| SM["Session Map: userId to Sessions"]
    end

    API_GATEWAY -->|"加载历史消息"| DB_MSG
    API_GATEWAY -->|"标记已读"| DB_MSG

2. 组件说明

2.1 前端组件 (Frontend Components)

  • WebSocketManager.js: 核心连接管理器。
    • 职责: 维护单例连接、自动重连（指数退避策略）、发送心跳（30s ping/pong）、消息 JSON 解析及发布订阅模式。
    • 鉴权: 从 localStorage 获取 Admin-Token 并通过 URL 参数传递。
  • WebSocketNotificationBell.vue: 顶部导航条的通知组件。
    • 职责: 展示实时通知、统计未读数、展示消息弹窗、与后端交互同步已读状态。
    • 逻辑: 首次加载时通过 REST API 获取历史消息，随后通过 WebSocket 接收实时增量消息。

2.2 后端组件 (Backend Components)

  • ChatHandshakeInterceptor: 握手拦截器。
    • 职责: 在 WebSocket 握手阶段利用 Sa-Token 验证 Token 的合法性，并将解析出的 userId 存入 WebSocket Session 的属性中。
  • ChatWebSocketHandler: 消息核心处理器。
    • 职责:
      • Session 管理: 在内存中维护 userId 到 Set<WebSocketSession> 的映射，支持同一用户多设备/多标签页同时在线。
      • 异步处理: 使用自定义线程池处理业务逻辑，防止 IO 阻塞 WebSocket 主线程。
      • 协议支持: 处理 PRIVATE_MESSAGE（私聊）、GROUP_MESSAGE（群聊）、PING（心跳）、MESSAGE_ACK（消息回执）等多种消息格式。
  • TaskExecutors: 线程池管理。
    • 职责: 隔离 WebSocket IO 线程与具体的业务处理逻辑。

2.3 存储机制 (Storage Mechanism)

  • 实时性: 消息优先推送给在线 Session。
  • 持久化:
    • chat_message: 存储全量消息历史。
    • chat_offline_message: 存储用户离线期间收到的消息，待用户上线后自动推送。
  • 消息回执 (ACK): 前端收到消息后发送 ACK，后端更新消息状态（已送达/已读），确保消息不丢失。

文档由 Antigravity 自动生成于 2026-03-24

]]>Luis Li赛博朋克 2026：前端幻象构建指南2026-03-23T15:30:00+08:002026-03-23T15:30:00+08:00https://luis-ai-systems.github.io/2026/03/23/cyberpunk-theme如何在使用极其贫瘠的 HTML 元素时，使用 CSS 魔法将其转换为具有“呼吸感”的赛博组件？

霓虹光效的秘密

实际上，利用 box-shadow 和多重渐变叠加，我们可以非常容易地突破矩形的桎梏。

“在黑暗中发光的，不只有恒星，还有那 1px 的边框。”

核心参数体验

下面是我平时最喜欢的一套按钮呼吸参数：

.cyber-button {
    box-shadow: 0 0 10px rgba(0, 255, 255, 0.5), 
                inset 0 0 10px rgba(0, 255, 255, 0.5);
    border: 1px solid #00ffff;
    transition: all 0.3s ease;
}
.cyber-button:hover {
    box-shadow: 0 0 20px rgba(0, 255, 255, 0.8), 
                inset 0 0 20px rgba(0, 255, 255, 0.8);
    transform: scale(1.05);
}

通过这样的叠加，元素在深色背景下会散发出如同全息投影一般的冷冽光芒。

]]>Luis Li记录一次深夜的系统崩溃与重启2026-03-22T02:14:00+08:002026-03-22T02:14:00+08:00https://luis-ai-systems.github.io/2026/03/22/server-crash昨天半夜，我的服务器毫无征兆地宕机了。

一切仿佛就像是《黑客帝国》里的断电瞬间。我赶紧从床上爬起来，打开终端，输入了那行熟悉的 SSH 命令。

拯救日志

翻看 dmesg 和 /var/log/syslog，发现竟然是因为某个不知名的死循环脚本耗尽了所有的内存，触发了 OOM Killer。

这提醒我们：

  1. 进程隔离是多么重要。
  2. 永远不要相信你匆忙写下、没有加 sleep 的 while True。

最终，我在长达两个小时的抢救后，系统终于恢复了它的跳动。看着满屏绿色的 [ OK ] 打印出来，那是一种程序员才能体会到的绝对浪漫。

]]>Luis Li