崔旭的笔记

JSDoc vs TypeScript 选型笔记

Tue, 11 Nov 2025 09:32:20 GMT

TL;DR

小而快、少改造 → 用 JSDoc：零编译、成本低，智能提示+基本类型检查够用。
多人协作、复杂模型、长期演进 → 上 TypeScript：强约束、类型表达力强、生态支持完整。
还不确定？先用 JSDoc“铺轨”，4 周后复盘：若出现类型灰区/重构痛点，再切 TS。

两条路线各自的价值

JSDoc（纯 JS + 注释）

✅ 零构建成本：不改语法，直接运行。
✅ 渐进引入：从公共 API 开始补，风险低。
✅ 编辑器体验好：配合 checkJs、@types/* 即可。
⚠️ 约束力弱：注释易缺失，无法“强制全覆盖”。
⚠️ 复杂类型表达受限：高级泛型/条件/映射类型较难。

最适合：中小型服务、内部应用、追求快和轻、不想上编译链的项目。

TypeScript（.ts 编译）

✅ 强约束：类型写进语法，覆盖更彻底。
✅ 表达力强：条件/映射/模板字面量等高级类型。
✅ 生态一等支持：工具链、生成 .d.ts、SDK/库发布友好。
⚠️ 需要编译：构建链与 CI 复杂度提升。
⚠️ 渐进成本：历史代码迁移需要计划与时间。

最适合：多人协作、复杂领域模型、公共库/SDK、长期维护和频繁重构的项目。

适用场景对比（速查表）

维度	JSDoc	TypeScript
上手/改造成本	低	中-高
类型严格度	中	高（可设 `strict`）
复杂类型建模	限制较多	很强
团队协作/重构	基本满足	最佳
发布库/SDK	勉强可行	一等公民
运行/构建复杂度	低	中-高
演进与长远性	中	高

决策树（按“是/否”走）

是否需要强约束（类型缺失视为错误）？ 是 → 倾向 TS；否 → 2
是否存在复杂领域模型/广泛复用的内部包？ 是 → TS；否 → 3
是否强烈希望零编译、保留纯 JS 运行链路？ 是 → JSDoc；否 → 4
团队对 TS 是否有经验/意愿维护构建？ 有 → TS；无 → 先 JSDoc，后评估升级

最小可用配置（落地模板）

路线 A：JSDoc（纯 JS）

jsconfig.json

{
  "compilerOptions": {
    "checkJs": true,
    "lib": ["ES2022"],
    "moduleResolution": "node",
    "types": ["node", "express"]
  },
  "include": ["src/**/*.js"],
  "exclude": ["dist", "node_modules"]
}

安装类型声明（开发依赖）：

npm i -D @types/node @types/express

在关键文件顶部可加：

// @ts-check

给公共 API/中间件/配置对象补 JSDoc（从“对外接口”开始，收益最大）。

路线 B：TypeScript（增量迁移）

tsconfig.json（最小严格模式）

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "outDir": "dist"
  },
  "include": ["src"]
}

增量迁移策略：
- 第 1 周：保留 JS 运行，新增 TS 构建（Babel/tsc 任一）。
- 第 2–3 周：核心域模型与公共模块改为 .ts。
- 第 4 周：把“边缘模块”迁移/隔离，补充 .d.ts 输出和 CI 阶段类型检查。

选型建议清单（给 Express 团队）

满足即可：内部服务、接口清晰、少人维护 → JSDoc。
追求稳健：多人、多模块、频繁重构、长期维护 → TS。
灰度策略：JSDoc 起步，记录“类型痛点”，当痛点达到阈值（如 3 次以上重构失误/PR 反复）→ 立项迁移 TS。

常见反模式与规避

JSDoc 只写几处：缺少全局 checkJs 或关键路径无注释 → 约束形同虚设。
编辑器与运行时别名不一致：jsconfig.paths 生效但 Node 不认；ESM 下用 package.json#imports 对齐。
TS 一上来全量重写：风险高、节奏乱；应优先迁移“被多处依赖的核心模块”。
TS 关掉严格模式：失去大量价值；若负担大，先放开个别规则而非整体关闭。

实操建议（一句话版）

能用 JSDoc 先解决 80% 问题就用 JSDoc；当复杂度与团队协作要求上来，再切 TypeScript。
把“是否迁移 TS”变成数据驱动的决策：统计类型相关故障/重构回滚次数、PR 讨论成本作为阈值。

需要的话，把你项目的目录结构与典型模块贴给我，我可以根据现状给出“JSDoc 够用 or 值得上 TS”的个性化建议与实施计划。

结合 Vite 和 Webpack 说一说打包工具都做了什么

Wed, 05 Nov 2025 07:40:11 GMT

1) 入口与模块图：把项目“地图”画出来

功能： 告诉工具“从哪儿开始找代码”，再顺着每个文件里的 import/require() 把所有会用到的文件串成一张网（依赖图）。 直觉类比： 从首页（入口）出发，顺着“超链接”（import）把整站爬一遍，得到网站地图。 Vite：

Dev：浏览器请求哪个模块，就现查现用地把它和它的依赖挂到图上。
Build：交给 Rollup 从入口把整张图一次走完。 Webpack：
不分 Dev/Prod，都是先把整张图建好再工作。 常用配置：
Vite：resolve.alias、build.rollupOptions.input
Webpack：entry、resolve.alias、resolve.extensions、resolve.mainFields

2) 模块解析与格式兼容：不同“口味”的文件都能吃

功能： 让 ESM、CommonJS、CSS、图片、JSON… 这些不同格式都能作为“模块”被导入。 直觉类比： 餐厅后厨收菜，有中餐配料、西餐配料、饮料、甜点——都要能接收并分门别类。 Vite： Dev 期用原生 ESM；遇到 CJS 用 esbuild 转成 ESM；CSS/图片会被转成“虚拟模块”。 Webpack： 用 loader 把各种格式变成 JS 能理解的模块；静态资源用 asset/* 类型统一管理。 配置抓手：

Vite：多数开箱即用；特殊包用 optimizeDeps.include/exclude。
Webpack：module.rules（css-loader/file-loader 等已被 asset 取代）、type:'asset/resource|inline|source'。

3) 源码转换（TS/JSX/ESNext）：把“新语法”变成“大家都懂的”

功能： 把 TS、JSX、以及浏览器还不完全支持的新 JS 语法，变成兼容目标环境的普通 JS。 直觉类比： 把方言翻译成普通话；再按不同城市口音做点适配。 Vite： Dev 用 esbuild 快速转；Build 用 Rollup 插件链 + esbuild；必要时再上 Babel。 Webpack： 常用 swc-loader / esbuild-loader（快）或 ts-loader + babel-loader（灵活）。 配置抓手：

Vite：esbuild.target、@vitejs/plugin-react/-vue。
Webpack：module.rules 里接对应 loader；目标环境通过 Babel/SWC 配置或 target。

4) 代码分割：该拆就拆，别一次塞完

功能： 把代码拆成若干 chunk；首屏先下关键的，其他页面或功能再按需加载。 直觉类比： 搬家别一次搬完全部家具，先把床和锅搬过去能住就行，其他慢慢运。 Vite（Rollup）： 遇到 import() 自动拆；可用 output.manualChunks 把第三方库/路由块分组。 Webpack： import() 变异步块；optimization.splitChunks 把公共依赖抽出来；runtimeChunk 拆运行时。 常见坑： 拆得太碎 → 请求多；拆得太粗 → 首屏肥。 配置抓手：

Vite：build.rollupOptions.output.manualChunks
Webpack：optimization.splitChunks、optimization.runtimeChunk

5) Tree Shaking：把没用到的函数“抖掉”

功能： 删除没有被引用的导出和死代码，减小体积。 直觉类比： 行李只带穿的衣服，压缩包里把没穿的都拿掉。 Vite： Rollup 基于 静态 ESM 天然能摇树，要注意包的 sideEffects 标注。 Webpack： usedExports + sideEffects + 压缩器 DCE 一起配合。 关键点： 第三方包要写 "sideEffects": false（或列出有副作用的文件），否则工具不敢删。

6) 压缩 + 作用域提升：把包尽量“压瘪”

功能： 压缩空格注释、缩短变量名；把多个小函数“内联”到一个作用域，进一步省体积。 直觉类比： 把衣服抽真空打包，能塞更小的行李箱。 Vite： 默认用 esbuild/terser 压缩；Rollup 自带激进 hoist。 Webpack： TerserPlugin / swcMinify / esbuildMinify；optimization.concatenateModules: true。 抓手：

Prod 必开压缩；若构建慢，可试 swc/esbuild 压缩器加速。

7) CSS 管线：样式也要编译、抽取、瘦身

功能： 支持 Sass/Less，跑 PostCSS（自动补前缀等），生产把 CSS 抽成独立文件并压缩。 直觉类比： 把布料（Sass）裁剪成衣服（CSS），最后折叠打包单独装袋。 Vite： 内置预处理、PostCSS；cssCodeSplit 控制是否按 chunk 拆 CSS。 Webpack： Dev 用 style-loader 直接插 <style>；Prod 用 MiniCssExtractPlugin 抽出 .css，再用 css-minimizer 压缩。 抓手： Tailwind/UnoCSS 这类原子化框架构建期会扫描类名，别忘了开启缓存。

8) 资源与哈希：文件要“可缓存又不串台”

功能： 小文件直接内联成 base64；大文件复制到输出目录并在文件名里带 contenthash，方便 CDN 长缓存。 直觉类比： 零食（小文件）直接放口袋；大家电（大文件）单独打包并标注“按内容生成的编号”。 Vite： assetsInlineLimit、产物默认带 hash。 Webpack： type:'asset' 系列统一；output.filename: [name].[contenthash].js。 关键点： “contenthash”基于内容，改一处不至于让所有文件名都变。

9) HTML 注入与启动：自动把产物挂到页面

功能： 把打包出来的 <script>/<link> 自己插到 HTML 里，顺便加预加载标签。 直觉类比： 菜做好了，自动摆盘上桌。 Vite： index.html 就是配置入口；自动注入入口脚本与关键 preload；import.meta.env 注环境变量。 Webpack： 用 html-webpack-plugin 读取模板并把资源注进去；需要时配 preload/prefetch 插件。 抓手： 多页面应用（MPA）就配多个入口/多个 HTML 插件实例。

10) Dev Server 与 HMR：改一行，页面“秒变”

功能： 起本地服务器、反向代理、支持热更新（只替换改动的模块，不整页刷新）。 直觉类比： 裁缝给你改衣服，改袖子不用让你把整套衣服脱下来。 Vite： 基于 ESM 的模块级热替换，**依赖预构建（esbuild）**把 node_modules 先“熬一锅”。 Webpack： webpack-dev-server + Runtime 补丁；图上只重建受影响的模块。 抓手： HMR 不稳的模块可先降级成整页刷新，先稳后快。

11) 缓存、并行与增量：速度来自“别重复干活”

功能： 把中间结果落盘、任务多进程并行、只重建受影响的那一小撮文件。 直觉类比： 裁缝把常用版型留底（缓存），多人同时干活（并行），衣服改口袋不必重做衣领（增量）。 Vite： .vite 目录缓存预构建与转换；Rollup/Esbuild 自带并行。 Webpack： cache:{ type:'filesystem' }、thread-loader、parallel、experiments.lazyCompilation。 抓手： 大仓项目开启文件系统缓存可以直接砍掉二次构建大半时间。

12) Source Map：线上出错也能看懂

功能： 让压缩后的代码能“对回去”原始源码，定位 Bug；生产可用隐藏 map配合错误上报。 直觉类比： 城市地铁图（压缩产物）配一张“对照表”（map），告诉你真实街道名（源码）。 Vite： build.sourcemap: true|'hidden'|'inline'（生产推荐 hidden）。 Webpack： devtool：开发常用 cheap-module-source-map，生产 hidden-source-map。 抓手： 别把完整 map 直接公开在生产站点；交给 Sentry 等平台私有存储。

可选项（按需添加的一揽子）

手工分包策略：Vite manualChunks / Webpack splitChunks.cacheGroups 精细切 vendor/路由块。
图片优化自动化：Vite vite-imagetools；Webpack image-minimizer-webpack-plugin。
预加载/预取精调：按路由/关键路径加 <link rel="preload/prefetch">。
旧浏览器兼容：Vite @vitejs/plugin-legacy；Webpack 降 targets + polyfill。
模块联邦（微前端）：Vite 社区插件；Webpack Module Federation。
SSR/SSG 同构：Vite 配 ssr 或直接用 Nuxt/SvelteKit 等；Webpack 走 target:'node' + externals。
PWA/Service Worker：Vite vite-plugin-pwa；Webpack workbox-webpack-plugin。
类型检查 / ESLint 并入构建：Vite vite-plugin-checker；Webpack fork-ts-checker-webpack-plugin。
体积分析与 CI 守门：rollup-plugin-visualizer / webpack-bundle-analyzer + 体积阈值。
哈希稳定性细化：Webpack moduleIds/chunkIds: 'deterministic'；合理固定 vendor 边界。
安全工艺：依赖审计、SRI、生产 Source Map 私有化。
i18n 构建期优化：提取文案、按语言分包。

一句话总括

把 12 步当“主干线”先跑通：能编译、能分包、能热更、能缓存、能定位错误。
有了瓶颈再从“可选项”里点菜：是首屏慢？体积大？冷启动慢？针对性加一两项就行。

jsconfig 配置及注意事项

Mon, 03 Nov 2025 11:13:48 GMT

jsconfig 配置的作用

在某个目录放一个 jsconfig.json，VS Code 就把它当作JavaScript 项目根。文件里定义项目包含的源文件与语言服务选项，从而影响智能提示、自动导入、转到定义、错误检查等编辑器体验。(Visual Studio Code)
VS Code 没有 jsconfig 也能工作，但当你的工作区里并非所有 JS 文件都属于同一个项目，或需要路径别名/包含范围等配置时，就应该创建它。(Visual Studio Code)
它本质上是 tsconfig.json 的“JS 版变体”，只作用于编辑器的 JS/JSX 语言服务（不参与打包）。(Visual Studio Code)

为什么/什么时候需要

VS Code JS 支持有两种模式：

File Scope（无 jsconfig）：每个文件独立，没有统一的项目上下文。
Explicit Project（有 jsconfig）：用 jsconfig.json 明确项目边界与解析规则。当你需要更准确的 IntelliSense、跨文件跳转、非相对导入/别名，建议使用 jsconfig。(GitHub)

常用配置项（高频）

include / exclude：工程边界。只把 src/ 等需要的目录纳入项目。(Visual Studio Code)
compilerOptions.baseUrl + paths：配置路径别名（如 @/），让 VS Code 能解析到定义并提供自动导入。(Visual Studio Code)
checkJs：对 .js/.jsx 做 TS 级别类型检查（配合 JSDoc 与 .d.ts）以发现更多类型错误。(Visual Studio Code)
jsx：设置 JSX 处理方式（如 React 17+ 的 react-jsx）。(Visual Studio Code)
其他常见：module、moduleResolution、resolveJsonModule、types 等，影响编辑器如何解析模块与可见的全局类型（例如 Node/React）。(Visual Studio Code)

小技巧：用命令面板 JavaScript: Go to Project Configuration 可检查当前文件是否被某个 jsconfig.json 管理。(Visual Studio Code)

与 tsconfig 的关系

语义上：jsconfig.json 是 tsconfig.json 的子集/对应物，用于纯 JS 项目；TS 项目应只维护 tsconfig.json（不要两者并存，避免冲突）。(Visual Studio Code)

常见坑

有 jsconfig 但 include 没覆盖源码（如漏了 src/），会导致“转到定义/自动导入”异常。(Visual Studio Code)
配了打包器 alias（如 Rsbuild/Vite/Webpack），却没在 jsconfig 同步 baseUrl/paths，编辑器跳转会失效（打包能过但编辑器不认）。(Visual Studio Code)
开启 checkJs 后导入 *.scss、*.jpg 等非 JS 资源需要 .d.ts 声明，不然会报“找不到模块/类型声明”。这是语言服务在做类型检查的预期行为。(Visual Studio Code)

和 Biome/ESLint/打包器的区别

维度	jsconfig.json	Biome
主要作用	配置 VS Code JavaScript 语言服务：项目边界、路径解析、类型检查选项（`checkJs`）等	格式化 + Lint 工具：风格统一、可疑代码模式、自动修复等
生效位置	编辑器内（tsserver），不参与打包	CLI/编辑器/CI，检查并修复代码风格与部分问题
能否做类型检查	可（对 JS 通过 `checkJs`+JSDoc/类型声明）	以规则式静态检查为主；不是完整的类型系统
是否影响打包	否	否（与 bundler 配置分离）

Biome 的定位是超快的格式化器 + Linter，替代 Prettier/ESLint 组合；它强调“格式化由 formatter 处理，lint 规则不覆盖格式化”，并提供大量分组规则与自动修复。(Biome)
Biome 不提供像 TS 那样的完整类型推断/检查；jsconfig 的 checkJs 则能把 .js/.jsx 纳入类型检查（配合 JSDoc 与声明），捕获 API 误用、形状不匹配等类型问题。(Visual Studio Code)
二者是互补关系：Biome 保证风格/常见陷阱；jsconfig 让编辑器理解你的项目结构与别名，并在需要时提供类型层面的保护。(Visual Studio Code)

给你的一份实用模板（纯 JS + React）

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": { "@/*": ["src/*"] },
    "jsx": "react-jsx",
    "checkJs": true, // 若暂不想要类型错误，可设为 false
    "module": "ESNext",
    "moduleResolution": "bundler",
    "resolveJsonModule": true,
    "types": ["react", "react-dom", "node"]
  },
  "include": ["src"],
  "exclude": ["dist", "node_modules"]
}

如果你开启了 checkJs，并且会 import './x.scss' 或图片等静态资源，请加一份最小的 assets.d.ts（告诉编辑器这些模块的“类型”），以避免无意义报错。(Visual Studio Code)

Laravel IDE Helper 使用笔记

Tue, 28 Oct 2025 03:51:06 GMT

📦 一、包简介

项目地址： https://github.com/barryvdh/laravel-ide-helper

作者：Barry vd. Heuvel 最新版本：v3.x支持 Laravel 10+

✅ 作用

laravel-ide-helper 是一个为 Laravel 项目生成 PHPDocs 的开发辅助工具。它可以让你的 IDE （PhpStorm / VS Code ）能够：

智能补全 Laravel Facade 方法
识别 Eloquent 模型的属性与关系
添加 IoC 容器解析类的类型提示
自动生成 macro / mixin / Fluent 方法文档

🔍 说白了：让 IDE 更懂 Laravel。

⚙️ 二、安装与配置

1. 安装

composer require --dev barryvdh/laravel-ide-helper

🛠️ 三、常用命令

1. Facade PHPDocs

php artisan ide-helper:generate

🔹 生成 _ide_helper.php，使 IDE 识别如 DB, Auth, Cache 等 Facade。

2. 生成模型注释

php artisan ide-helper:models -RW

参数	含义
`-W`	写入模型文件中
`-N`	不写入模型，只生成文件
`-R`	重置注释
`-M`	仅添加 `@mixin` 标记
`-E`	生成 `_ide_helper_eloquent.php` 简版

🔍 需正常数据库连接。

3. PhpStorm Meta 文件

php artisan ide-helper:meta

🔹 生成 .phpstorm.meta.php 文件，使 PhpStorm 能识别 app('events')等的对象类型。

🧩 四、进阶功能

1. Composer 自动生成

"scripts": {
  "post-update-cmd": [
    "@php artisan ide-helper:generate",
    "@php artisan ide-helper:meta"
  ]
}

2. Fluent 方法支持

开启后，IDE 可识别 $table->string()->nullable()->index();

'include_fluent' => true,

3. Macros / Mixins

当使用 Str::macro() 时，如果定义有类型提示，IDE Helper 会自动生成相应 PHPDocs。

4. 自定义 Model Hooks

允许在模型生成过程中动态添加属性或方法：

'model_hooks' => [
   MyCustomHook::class,
],

5. 忽略某些模型

php artisan ide-helper:models --ignore="App\Models\User,App\Models\Post"

📂 五、生成文件解释

文件	用途
`_ide_helper.php`	Facade 和 macro 文档
`_ide_helper_models.php`	模型属性与关系
`.phpstorm.meta.php`	IoC 容器提示
`config/ide-helper.php`	配置文件

🖊️ 六、使用建议

仅在开发环境下使用
将 _ide_helper.php 等添加到 .gitignore
确保数据库连接正常
定期更新生成文件

🔺 七、总结

优点	说明
🔍 IDE 智能补全	加强代码推断能力
📝 自动生成	基于代码和数据库分析
⚙️ 可配置	可自定义路径和生成方式
💡 PhpStorm 集成	自动识别 IoC 对象

总结：laravel-ide-helper 是 Laravel 开发者必备的辅助工具，可以大大提升代码编写效率和维护性。

不同系统中的卷（Volume）与分区管理对比

Fri, 24 Oct 2025 04:33:10 GMT

一、基本概念

“卷（Volume）”是存储空间的逻辑单位。不同操作系统对“卷”的定义和管理方式不同：

Windows 以固定分区为主；
macOS (APFS) 采用共享空间的容器模型；
Linux 使用 LVM（逻辑卷管理）实现灵活可扩展的结构。

二、三大系统卷管理方式对比

系统	底层技术	结构层次	空间分配机制	是否自动共享空间	是否支持跨硬盘	是否可加密	调整难度
Windows	NTFS 分区	硬盘 → 分区	每个分区固定大小	❌ 否	❌ 否	BitLocker	高（需重新分区）
macOS	APFS 容器 + 卷	硬盘 → 容器 → 卷	容器内卷共享空间	✅ 是	❌ 否	✅ 原生支持 (APFS Encrypted)	极低（自动）
Linux	LVM（PV → VG → LV）	硬盘 → 分区 → 物理卷 → 卷组 → 逻辑卷	卷组内卷可手动调整大小	⚙️ 半自动（需命令调整）	✅ 可将多盘合并	✅ LUKS / dm-crypt	中等（需命令行）

三、形象理解

系统	类比场景	特点
Windows	固定大小的房间	空间一旦划定就不能自动调整。
macOS (APFS)	多人共享仓库	所有卷共享一个空间池，自动伸缩。
Linux (LVM)	模块化仓库	管理员可自由扩展、合并或缩小卷组。

四、文件系统与大小写敏感性

系统	常见文件系统	是否区分大小写	说明
Windows	NTFS / exFAT / FAT32	默认不区分	对大小写敏感软件不友好。
macOS	APFS / HFS+	可选（Case-sensitive 或不敏感）	默认不区分；开发环境可选敏感模式。
Linux	ext4 / XFS / Btrfs / ZFS	默认区分	文件系统天然区分大小写。

五、加密机制对比

系统	加密方式	特点
Windows	BitLocker	简单易用，系统集成。
macOS	APFS (Encrypted) / FileVault	系统级集成，安全方便。
Linux	LUKS + LVM	灵活可组合，适合进阶使用者。

六、操作方式示例

1️⃣ macOS 新建卷（Case-insensitive）

打开 磁盘工具 (Disk Utility)
选中 APFS 容器 → 点击 “+”
格式选择 APFS 或 APFS (Encrypted)（不要选 Case-sensitive）
完成后复制数据过去即可使用

→ 所有卷自动共享同一空间。

2️⃣ Linux LVM 示例

# 创建物理卷
sudo pvcreate /dev/sda1 /dev/sdb1

# 创建卷组
sudo vgcreate vg_data /dev/sda1 /dev/sdb1

# 创建逻辑卷
sudo lvcreate -L 200G -n lv_backup vg_data

# 格式化
sudo mkfs.ext4 /dev/vg_data/lv_backup

# 扩容示例
sudo lvextend -L +100G /dev/vg_data/lv_backup
sudo resize2fs /dev/vg_data/lv_backup

七、总结一句话

💬 Windows 是固定的，macOS 是自动的，Linux 是灵活的。

Windows：每个分区独立，调整麻烦。
macOS：卷共享空间，系统自动伸缩。
Linux：通过 LVM 灵活管理、扩展和加密空间。

为什么不应该在 Sidebar 组件中直接使用 useSessions Hook

Thu, 21 Aug 2025 06:59:14 GMT

引言

在 React 开发中，我们经常面临一个重要的架构决策：是否应该让组件直接使用业务逻辑 hooks，还是通过 props 传递数据和回调函数？本文将通过一个实际的聊天应用案例，分析为什么建议保持组件的数据流清晰，而不是在组件中直接使用业务逻辑 hooks。

问题背景

在我们的聊天应用中，有一个 Sidebar 组件负责显示聊天会话列表。最初的设计是：

// 当前架构：通过 props 传递数据
<Sidebar
  sessions={sessions}
  currentSessionId={currentSessionId}
  onSelectSession={selectSession}
  onNewSession={createNewSession}
  onDeleteSession={deleteSession}
  isOpen={sidebarOpen}
  onToggle={() => setSidebarOpen(!sidebarOpen)}
/>

有人可能会问：为什么不直接在 Sidebar 组件中使用 useSessions hook 呢？

// 不推荐的架构：直接在组件中使用 hook
export function Sidebar() {
  const {
    sessions,
    currentSessionId,
    selectSession,
    createNewSession,
    deleteSession,
  } = useSessions();
  // ...
}

为什么不建议在组件中直接使用业务逻辑 Hooks？

1. 关注点分离 (Separation of Concerns)

组件应该专注于 UI 渲染，而不是业务逻辑

// ✅ 好的做法：纯展示组件
export function Sidebar({
  sessions,
  onSelectSession,
  onNewSession,
  onDeleteSession,
}) {
  return (
    <div>
      {sessions.map((session) => (
        <button key={session.id} onClick={() => onSelectSession(session.id)}>
          {session.title}
        </button>
      ))}
    </div>
  );
}

// ❌ 不好的做法：组件混合了业务逻辑
export function Sidebar() {
  const { sessions, selectSession } = useSessions(); // 业务逻辑混入组件
  // ...
}

2. 可测试性 (Testability)

纯组件更容易进行单元测试

// ✅ 容易测试：只需要模拟 props
test("Sidebar renders sessions correctly", () => {
  const mockSessions = [
    { id: "1", title: "Chat 1" },
    { id: "2", title: "Chat 2" },
  ];

  render(<Sidebar sessions={mockSessions} onSelectSession={jest.fn()} />);

  expect(screen.getByText("Chat 1")).toBeInTheDocument();
  expect(screen.getByText("Chat 2")).toBeInTheDocument();
});

// ❌ 难以测试：需要模拟 hook 和依赖
test("Sidebar with useSessions", () => {
  // 需要模拟 useSessions hook
  jest.mock("./useSessions", () => ({
    useSessions: () => ({
      sessions: mockSessions,
      selectSession: jest.fn(),
    }),
  }));
  // 测试变得复杂...
});

3. 可复用性 (Reusability)

纯组件可以在不同场景下复用

// ✅ 可以在不同场景下复用
// 场景1：聊天应用
<Sidebar sessions={chatSessions} onSelectSession={handleChatSelect} />

// 场景2：文件管理器
<Sidebar sessions={fileSessions} onSelectSession={handleFileSelect} />

// 场景3：测试环境
<Sidebar sessions={mockSessions} onSelectSession={mockHandler} />

4. 状态管理集中化 (Centralized State Management)

所有状态变化都在一个地方管理，便于调试

// ✅ 状态管理集中化
export function useChat() {
  const { sessions, selectSession, createNewSession, deleteSession } =
    useSessions();
  const { messages, sendMessage } = useMessages();
  const { user, logout } = useAuth();

  // 所有业务逻辑都在这里
  const handleSessionSelect = async (sessionId: string) => {
    await selectSession(sessionId);
    await loadMessages(sessionId);
  };

  return {
    sessions,
    onSelectSession: handleSessionSelect,
    // ...
  };
}

5. 数据流清晰 (Clear Data Flow)

遵循 React 的数据流原则：props 向下，事件向上

// ✅ 清晰的数据流
App
├── useChat (业务逻辑层)
│   ├── useSessions
│   ├── useMessages
│   └── useAuth
└── Chat (组件层)
    └── Sidebar (纯展示组件)
        ├── sessions (props 向下)
        ├── onSelectSession (事件向上)
        └── onNewSession (事件向上)

6. 便于调试和维护 (Debugging and Maintenance)

当出现问题时，可以快速定位到业务逻辑层

// ✅ 问题定位清晰
// 如果会话选择有问题，直接查看 useChat 中的 handleSessionSelect
// 如果 UI 显示有问题，直接查看 Sidebar 组件的渲染逻辑

// ❌ 问题定位困难
// 如果直接在 Sidebar 中使用 useSessions，问题可能分散在多个地方

实际案例分析

让我们看看当前项目中的实现：

当前架构的优势

// useChat.ts - 业务逻辑集中管理
export function useChat() {
  const { sessions, selectSession, createNewSession, deleteSession } =
    useSessions();

  // 包装业务逻辑，添加额外的处理
  const selectSessionWrapper = async (sessionId: string) => {
    clearMessages(); // 清除当前消息
    setRequest(""); // 清空输入
    setError(""); // 清除错误
    await selectSession(sessionId);
    await loadChatMessages(sessionId); // 加载消息
  };

  return {
    sessions,
    onSelectSession: selectSessionWrapper,
    // ...
  };
}

// Chat.tsx - 组件层
export function Chat() {
  const { sessions, onSelectSession, onNewSession, onDeleteSession } =
    useChat();

  return (
    <Sidebar
      sessions={sessions}
      onSelectSession={onSelectSession}
      onNewSession={onNewSession}
      onDeleteSession={onDeleteSession}
    />
  );
}

// Sidebar.tsx - 纯展示组件
export function Sidebar({
  sessions,
  onSelectSession,
  onNewSession,
  onDeleteSession,
}) {
  return (
    <div>
      {sessions.map((session) => (
        <button key={session.id} onClick={() => onSelectSession(session.id)}>
          {session.title}
        </button>
      ))}
    </div>
  );
}

如果直接在 Sidebar 中使用 useSessions 的问题

// ❌ 不推荐的实现
export function Sidebar() {
  const { sessions, selectSession, createNewSession, deleteSession } =
    useSessions();
  const { clearMessages, loadChatMessages } = useMessages(); // 需要额外的 hook

  const handleSelectSession = async (sessionId: string) => {
    clearMessages(); // 业务逻辑混入组件
    await selectSession(sessionId);
    await loadChatMessages(sessionId);
  };

  return (
    <div>
      {sessions.map((session) => (
        <button
          key={session.id}
          onClick={() => handleSelectSession(session.id)}
        >
          {session.title}
        </button>
      ))}
    </div>
  );
}

何时可以考虑在组件中使用 Hooks？

虽然我们建议保持组件的数据流清晰，但在某些特定情况下，可以考虑在组件中直接使用 hooks：

1. UI 相关的 Hooks

// ✅ 适合在组件中使用：UI 相关的 hooks
export function Sidebar() {
  const [isOpen, setIsOpen] = useState(false);
  const isMobile = useMediaQuery("(max-width: 768px)");

  return (
    <div className={isMobile ? "mobile-layout" : "desktop-layout"}>
      {/* ... */}
    </div>
  );
}

2. 组件内部状态管理

// ✅ 适合在组件中使用：组件内部状态
export function Sidebar() {
  const [searchTerm, setSearchTerm] = useState("");
  const [sortBy, setSortBy] = useState("date");

  const filteredSessions = useMemo(() => {
    return sessions.filter((session) =>
      session.title.toLowerCase().includes(searchTerm.toLowerCase()),
    );
  }, [sessions, searchTerm]);

  return (
    <div>
      <input
        value={searchTerm}
        onChange={(e) => setSearchTerm(e.target.value)}
      />
      {filteredSessions.map((session) => (
        <SessionItem key={session.id} session={session} />
      ))}
    </div>
  );
}

3. 第三方库的 Hooks

// ✅ 适合在组件中使用：第三方库的 hooks
export function Sidebar() {
  const { data, loading, error } = useQuery(["sessions"], fetchSessions);
  const { mutate: deleteSession } = useMutation(deleteSessionApi);

  if (loading) return <Spinner />;
  if (error) return <ErrorMessage error={error} />;

  return (
    <div>
      {data.map((session) => (
        <SessionItem key={session.id} session={session} />
      ))}
    </div>
  );
}

最佳实践总结

1. 分层架构

业务逻辑层 (Hooks)
├── useChat
├── useSessions
├── useMessages
└── useAuth

组件层 (Components)
├── Chat
├── Sidebar
├── MessageList
└── ChatInput

2. 数据流原则

Props 向下传递：数据从父组件流向子组件
事件向上传递：用户交互从子组件流向父组件
业务逻辑集中：所有业务逻辑都在 hooks 中处理

3. 组件设计原则

单一职责：每个组件只负责一个功能
纯函数：组件应该是纯函数，相同的 props 产生相同的输出
可测试：组件应该易于测试
可复用：组件应该可以在不同场景下复用

结论

虽然在某些情况下可以在组件中直接使用业务逻辑 hooks，但为了保持代码的可维护性、可测试性和可复用性，建议遵循以下原则：

保持组件的数据流清晰：通过 props 传递数据，通过回调函数处理事件
集中管理业务逻辑：将所有业务逻辑放在专门的 hooks 中
关注点分离：组件专注于 UI 渲染，hooks 专注于业务逻辑
遵循 React 最佳实践：props 向下，事件向上

这种架构模式不仅符合 React 的设计理念，也为项目的长期维护和扩展奠定了良好的基础。

本文基于实际项目经验总结，希望对您的 React 开发有所帮助。如果您有任何问题或建议，欢迎讨论交流。

Zustand Store 状态同步问题分析与解决方案

Sat, 02 Aug 2025 04:53:07 GMT

问题背景

在使用 Zustand 构建复杂状态管理时，经常会遇到需要组合多个子 store 的场景。本文通过一个实际案例，分析了在组合 store 时遇到的状态同步问题，并提供了相应的解决方案。

问题描述

原始代码结构

const useDeviceStore = create((set, get) => ({
  // 问题：这种方式只获取初始状态，不会响应子store的变化
  ...useDeviceIdentityStore.getState(),
  ...useNetworkStatusStore.getState(),
  ...useOperationStatusStore.getState(),
  ...useDeviceInfoStore.getState(),

  _initialized: false,
  init: async () => {
    // 初始化逻辑
    await useDeviceIdentityStore.getState().init();
    set({ _initialized: true });
  },
}));

// src/pages/mainTab/index.jsx - 组件使用
const MainTab = () => {
  const deviceId = useDeviceStore((state) => state.deviceId); // 始终为空
  const accessCode = useDeviceStore((state) => state.accessCode); // 始终为空
  // ...
};

问题现象

设备初始化成功（控制台显示 deviceId: 'E00E40', accessCode: 'CJRA88'）
但组件中获取到的 deviceId 和 accessCode 始终为空字符串
子 store 状态正常，主 store 状态不同步

问题根源

状态组合方式错误：使用 ...useDeviceIdentityStore.getState() 只会在 store 创建时获取一次初始状态，不会建立响应式连接。当子 store 状态更新时，主 store 不会自动同步。

解决方案对比

方案1：订阅机制（推荐）

优点：

保持原有 API 结构
自动状态同步
类型安全
易于维护

缺点：

代码稍复杂
需要额外的订阅逻辑

// src/store/device/index.js - 修复后的主 store
const useDeviceStore = create((set, get) => ({
  _initialized: false,
  init: async () => {
    await useDeviceIdentityStore.getState().init();
    set({ _initialized: true });
  },
}));

// 订阅子store的变化并同步到主store
useDeviceIdentityStore.subscribe((state) => {
  useDeviceStore.setState({
    deviceId: state.deviceId,
    accessCode: state.accessCode,
  });
});

useNetworkStatusStore.subscribe((state) => {
  useDeviceStore.setState({
    networkConnectedStatus: state.networkConnectedStatus,
  });
});

方案2：直接使用子 store

优点：

实现简单
性能更好（减少一层代理）
状态直接响应

缺点：

破坏原有 API 结构
组件需要知道具体的子 store
可能导致组件耦合度增加

// src/pages/mainTab/index.jsx - 直接使用子 store
import useDeviceIdentityStore from "@/store/device/deviceIdentity";
import useNetworkStatusStore from "@/store/device/networkStatus";
import useDeviceInfoStore from "@/store/device/deviceInfo";

const MainTab = () => {
  const deviceId = useDeviceIdentityStore((state) => state.deviceId);
  const accessCode = useDeviceIdentityStore((state) => state.accessCode);
  const networkConnectedStatus = useNetworkStatusStore(
    (state) => state.networkConnectedStatus,
  );
  const linkStatus = useDeviceInfoStore((state) => state.linkStatus);
  // ...
};

最终选择

根据项目实际情况，我们选择了方案2，原因如下：

简单直接：避免了复杂的订阅逻辑
性能优化：减少了不必要的状态代理
代码清晰：组件直接使用需要的子 store，意图明确
维护性好：减少了中间层，降低了复杂度

修复后的代码

// src/pages/mainTab/index.jsx
import useDeviceIdentityStore from "@/store/device/deviceIdentity";
import useNetworkStatusStore from "@/store/device/networkStatus";
import useDeviceInfoStore from "@/store/device/deviceInfo";

const MainTab = () => {
  // 直接从对应的子 store 获取状态
  const deviceId = useDeviceIdentityStore((state) => state.deviceId);
  const accessCode = useDeviceIdentityStore((state) => state.accessCode);
  const networkConnectedStatus = useNetworkStatusStore(
    (state) => state.networkConnectedStatus,
  );
  const linkStatus = useDeviceInfoStore((state) => state.linkStatus);
  const updateAccessCode = useDeviceIdentityStore(
    (state) => state.updateAccessCode,
  );

  // 现在 deviceId 和 accessCode 能正确获取到值
  console.log("deviceId:", deviceId); // 'E00E40'
  console.log("accessCode:", accessCode); // 'CJRA88'

  // ... 其他组件逻辑
};

经验总结

避免静态状态组合：不要使用 ...store.getState() 来组合状态
选择合适的状态管理策略：
- 简单场景：直接使用子 store
- 复杂场景：使用订阅机制
保持状态响应性：确保状态变化能够正确传播
考虑性能影响：减少不必要的状态代理和订阅

Socket.io 中间件机制与错误事件传递详解

Thu, 17 Jul 2025 08:30:35 GMT

中间件机制（Middleware）

什么是 Socket.io 中间件

Socket.io 中间件是在客户端连接建立之前执行的函数，用于验证、授权或预处理连接请求。

中间件的执行时机

客户端发起连接 → 中间件验证 → 连接建立/拒绝 → 触发相应事件

基本语法结构

io.use((socket, next) => {
  // 验证逻辑
  if (验证通过) {
    next(); // 继续连接流程
  } else {
    next(new Error("错误信息")); // 拒绝连接并传递错误
  }
});

中间件参数详解

socket: 即将建立的 socket 连接对象，包含 handshake 信息
next: 回调函数，控制中间件流程的继续或中断

错误事件传递机制

服务端错误传递

// ✅ 正确方式：在中间件中传递错误
io.use((socket, next) => {
  try {
    const token = socket.handshake.auth.token;
    if (!token) {
      // 通过 next 传递错误到客户端
      return next(new Error("Authentication error: No token provided"));
    }

    jwt.verify(token, SECRET_KEY);
    next(); // 验证通过，继续连接
  } catch (err) {
    // JWT验证失败
    next(new Error("Authentication error: Invalid token"));
  }
});

客户端错误接收

const socket = io({
  auth: {
    token: "your_token_here",
  },
});

// 连接成功事件
socket.on("connect", () => {
  console.log("✅ 连接成功");
});

// 连接错误事件 - 接收中间件传递的错误
socket.on("connect_error", (error) => {
  console.log("❌ 连接失败:", error.message);
  // error.message 包含服务端 next(new Error()) 中的错误信息
});

对比：正确 vs 错误的实现方式

❌ 错误方式：连接后断开

// 问题：连接已建立，disconnect 不会触发 connect_error
io.on("connection", (socket) => {
  const token = socket.handshake.auth.token;
  if (!token) {
    socket.disconnect(true); // 客户端不会收到 connect_error
    return;
  }
});

问题分析：

连接已成功建立
socket.disconnect() 只是断开连接，不是连接失败
客户端先收到 connect 事件，然后收到 disconnect 事件
客户端的 connect_error 事件永远不会触发

✅ 正确方式：中间件验证

// 解决方案：在连接建立前验证
io.use((socket, next) => {
  const token = socket.handshake.auth.token;
  if (!token) {
    next(new Error("No token provided")); // 正确触发 connect_error
    return;
  }
  next(); // 验证通过
});

优势：

连接根本不会建立
客户端直接收到 connect_error 事件
错误信息清晰传递
资源使用更高效

中间件的执行流程

多个中间件的执行顺序

// 中间件1：基础验证
io.use((socket, next) => {
  console.log("中间件1：基础验证");
  next();
});

// 中间件2：Token验证
io.use((socket, next) => {
  console.log("中间件2：Token验证");
  const token = socket.handshake.auth.token;
  if (!token) {
    return next(new Error("Missing token"));
  }
  next();
});

// 中间件3：权限检查
io.use((socket, next) => {
  console.log("中间件3：权限检查");
  // 其他验证逻辑...
  next();
});

执行顺序：按注册顺序依次执行，任何一个中间件调用 next(error) 都会中断流程。

中间件中的数据传递

io.use((socket, next) => {
  try {
    const decoded = jwt.verify(token, SECRET_KEY);
    // 将解码后的用户信息挂载到 socket 对象
    socket.user = decoded;
    next();
  } catch (err) {
    next(new Error("Invalid token"));
  }
});

// 在连接处理器中可以访问 socket.user
io.on("connection", (socket) => {
  console.log("用户信息:", socket.user); // 可以访问中间件中设置的数据
});

实际应用场景

1. JWT Token 验证

io.use((socket, next) => {
  const token = socket.handshake.auth.token;
  if (!token) {
    return next(new Error("Authentication required"));
  }

  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET);
    socket.userId = decoded.userId;
    socket.userRole = decoded.role;
    next();
  } catch (err) {
    next(new Error("Invalid authentication token"));
  }
});

2. IP 白名单验证

io.use((socket, next) => {
  const clientIP = socket.handshake.address;
  const allowedIPs = ["127.0.0.1", "192.168.1.0/24"];

  if (!isIPAllowed(clientIP, allowedIPs)) {
    return next(new Error("IP address not allowed"));
  }
  next();
});

3. 连接频率限制

const connectionAttempts = new Map();

io.use((socket, next) => {
  const clientIP = socket.handshake.address;
  const now = Date.now();
  const attempts = connectionAttempts.get(clientIP) || [];

  // 清理1分钟前的记录
  const recentAttempts = attempts.filter((time) => now - time < 60000);

  if (recentAttempts.length >= 10) {
    return next(new Error("Too many connection attempts"));
  }

  recentAttempts.push(now);
  connectionAttempts.set(clientIP, recentAttempts);
  next();
});

最佳实践总结

始终使用中间件进行连接前验证
通过 next(new Error()) 传递具体的错误信息
在中间件中设置 socket 属性，供后续使用
保持中间件逻辑简洁和高效
合理组织多个中间件的执行顺序
在客户端正确处理 connect_error 事件

这样的机制确保了 Socket.io 应用的安全性和用户体验的一致性。

Loki 和 Sentry 的适用场景对比

Sat, 28 Jun 2025 06:28:10 GMT

在选择 Grafana Loki 和 Sentry 时，需根据你的需求（如错误跟踪、日志管理、部署复杂度和预算）进行权衡。以下是对两者在错误跟踪和日志管理方面的对比，以及选择建议，结合了你的上一个问题（Loki 单体模式部署）及搜索结果的上下文。

1. 概述

Grafana Loki：轻量级日志聚合系统，专注于存储和查询日志，设计上类似 Prometheus，强调高效和低成本。适合集中化日志管理和查询，尤其与 Grafana 仪表板集成时效果最佳。
Sentry：专注于错误跟踪和性能监控，提供详细的错误堆栈、上下文和调试信息，同时支持日志摄取。适合开发团队快速定位和修复代码问题。

2. 对比分析

特性	Grafana Loki	Sentry
主要功能	日志聚合与查询	错误跟踪、性能监控、部分日志功能
日志管理	专为日志设计，支持海量日志存储和查询（如通过 LogQL）。适合基础设施和应用日志集中管理。	支持日志摄取，但日志功能较弱，主要作为错误上下文的补充。
错误跟踪	不提供原生错误跟踪功能，需依赖其他工具（如 Grafana Tempo 或 Sentry）来补充。	强大的错误跟踪能力，提供详细堆栈跟踪、用户上下文和重现步骤，适合开发调试。
可视化	与 Grafana 深度集成，提供灵活的仪表板和日志可视化。	自带仪表板，专注于错误和性能趋势，定制化程度低于 Grafana。
部署复杂性	单体模式简单（Docker/Helm 部署，参考上文），但微服务模式复杂。适合 Kubernetes 环境。	SaaS 为主，开箱即用；自托管选项存在，但配置较复杂。
成本	开源免费，成本主要来自存储和基础设施（如 S3）。	免费层有限，付费计划按事件量计费，成本可能较高。
集成性	与 Prometheus、Tempo 和 Grafana 生态无缝集成，适合全栈可观测性。	支持多种语言和框架，可与 Grafana 集成（如通过插件将 Sentry 数据可视化）。
适用场景	- 日志量大、需集中存储和查询<br>- 已有 Grafana 生态<br>- 预算有限	- 需深入错误调试<br>- 开发团队关注代码健康<br>- 愿意为 SaaS 付费

3. 选择建议

基于你的问题背景（询问 Loki 单体模式部署），推测你可能倾向于简单、开源的解决方案。以下是具体建议：

选择 Loki 的场景：
- 你需要一个集中化日志系统来管理基础设施或应用日志（例如 Kubernetes 日志、服务器日志）。
- 你已经使用或计划使用 Grafana 生态（Prometheus、Tempo、Grafana），希望通过 Grafana 仪表板实现统一的日志和指标可视化。
- 你倾向于开源和低成本，愿意自托管并接受单体模式（参考上文 Docker/Helm 部署）。
- 选择 Sentry 的场景：
  - 你的主要需求是错误跟踪，希望快速定位代码问题（如 Python 异常、JavaScript 错误）。
  - 你需要详细的错误上下文（堆栈跟踪、用户会话、设备信息）来加速调试。
  - 你更倾向于SaaS 解决方案，不想过多管理基础设施。
  - 你预算允许按事件量付费，或仅需免费层支持小规模项目。
组合使用：
- 如果你需要全栈可观测性（日志 + 错误跟踪），可以结合两者：
  - 用 Loki 存储和查询日志，** 利用其高效的日志聚合能力。
  - 用 Sentry 处理错误跟踪，补充 Loki 的不足。
  - 通过 Grafana 的 Sentry 插件，将 Sentry 的事件数据导入 Grafana 仪表板，实现统一监控。
- 这种方法适合有 Grafana 生态且开发团队需要深入调试的场景。许多团队将基础设施日志送至 Loki，应用错误日志送至 Sentry。
针对你的单体模式需求：
- 如果你选择 Loki 的单体模式（可能是测试或小规模部署），Loki 是更合适的起点。它的单体模式部署（Docker 或 Helm）简单，适合快速验证日志功能（参考上文）。但如果你发现需要错误跟踪，需额外集成 Sentry 或 Grafana Tempo。

4. 总结

优先 Loki：如果你专注于日志管理、已有 Grafana 生态、或预算有限，Loki 单体模式是低成本、高效率的选择。
优先 Sentry：如果你更关心错误跟踪和代码调试，Sentry 的专业功能更适合开发团队。
组合方案：Loki 用于日志，Sentry 用于错误，搭配 Grafana 可视化，适合复杂需求。

如果你有更具体的场景细节（如日志量、语言框架、是否已有 Grafana），我可以进一步优化建议！

Intro Trickle Ice

Wed, 25 Jun 2025 06:50:21 GMT

Trickle ICE（增量式 ICE）是一种优化WebRTC连接建立速度的技术，属于 Interactive Connectivity Establishment (ICE) 机制的一种扩展方式。

一、基本概念与原理：

传统的 ICE 流程是：

候选地址收集：获取所有网络接口的本地候选地址（如本地IP、STUN服务器反射地址、TURN服务器中继地址）。
候选地址交换：候选地址完全收集完成后，一次性发送给对端（通常通过SDP）。
连接检查：双方获取地址后尝试相互连接，找到可用的路径并建立媒体通信。

但这个过程存在一个问题：

收集地址可能需要一定时间，特别是STUN、TURN服务器响应可能较慢。 因此，在传统模式下，ICE需要等待候选地址完全收集完毕后再交换，延迟较高。

为优化连接建立速度，Trickle ICE 被提出：

增量式发送候选地址，而非一次性发送全部。
只要有新的候选地址出现，就立即发送给对方。
对方收到后也会立即开始连接检查，不再等待完整候选地址列表。

二、Trickle ICE的工作流程：

步骤：

发起Offer

Caller (Offerer)创建一个初始Offer，通常携带已有的少量候选地址（或为空），标明使用a=ice-options:trickle。
快速响应Answer

被呼叫方（Answerer）尽快响应Answer（也可能是空或少量地址），也标注a=ice-options:trickle。
增量发送候选（Trickling）

双方后续每次获得新候选地址时，都通过信令通道单独传送给对方，不再等待所有候选地址完全收集完毕。
连接检查同步进行

每收到一个候选地址，双方立即开始对该地址进行连通性检查（connectivity check）。
连接建立

一旦某条路径通过连接检查成功，就建立连接并开始媒体通信。
Trickle ICE 完成标记

当候选地址全部发送完毕后，会发送一个特殊标记表示候选地址收集完成，例如end-of-candidates。

三、Trickle ICE的优势：

更快的连接建立

候选地址收集和连接检查并行进行，连接延迟大幅降低（从几秒降低到几百毫秒）。
灵活性提升

特别适用于移动或不稳定的网络环境中，可以快速响应网络状况变化。

四、典型应用场景：

实时音视频通信（如WebRTC通话、视频会议、语音通话）。
实时游戏或协作应用，对连接建立时延敏感的场景。

五、Trickle ICE示例SDP片段：

Offer示例：

v=0
...
a=ice-options:trickle
a=candidate:1 1 UDP 2130706431 192.0.2.1 3478 typ host

之后，通过信令通道逐步发送新候选：

{
  "candidate": "candidate:2 1 UDP 1694498815 198.51.100.1 8998 typ srflx raddr 192.0.2.1 rport 3478",
  "sdpMid": "audio",
  "sdpMLineIndex": 0
}

候选地址发送完毕：

{
  "candidate": "",
  "sdpMid": "audio",
  "sdpMLineIndex": 0
}

六、需要注意的问题：

信令通道要求

需要支持实时的候选地址推送。
兼容性

部分老旧设备或客户端可能不支持Trickle ICE，需要提供回退方案（即ICE完成后再交换完整的候选地址）。

七、与非Trickle ICE的对比总结：

特性	非Trickle ICE（传统）	Trickle ICE（增量式）
候选地址发送	一次性全部发送	逐步增量发送
连接延迟	较高（数秒）	较低（毫秒级）
兼容性	好	较新，可能需要兼容性处理
复杂性	较低	略高

总结

Trickle ICE 显著提高了连接建立的速度，成为WebRTC实时通信领域的最佳实践之一。实际开发过程中，建议优先使用Trickle ICE，并考虑适当的回退机制以兼容老旧设备和客户端。

Node.js 和 Go：哪个更适合写爬虫？

Wed, 23 Oct 2024 08:54:27 GMT

在实现站点爬取和内容分析时，Node.js 和 Go 是两种常见的选择。它们各有优劣，适合不同的场景。本文将从性能、开发效率、并发处理和复杂网页支持等方面对两者进行详细对比，帮助你根据项目需求做出选择。

1. 性能对比

Go：作为编译型语言，Go 的性能非常优越，尤其适合处理高并发任务。Go 内置的 goroutines 使得并发爬取变得简单高效，在处理大量网络请求时表现尤为突出。
Node.js：Node.js 基于事件驱动的异步非阻塞模型，在 I/O 密集型任务中表现良好。然而，由于其是解释型语言，性能稍逊于 Go。在处理大量任务时，可能会遇到内存和性能瓶颈。

适用场景：如果项目对高并发和高性能有较高要求，Go 是更好的选择。

2. 开发效率与生态

Go：Go 的语法简洁，开发效率高，错误处理清晰，适合编写健壮的爬虫程序。然而，Go 的网页解析库相对较少，处理 HTML 等操作时需要更多手动工作。
Node.js：Node.js 拥有丰富的第三方库和工具，例如 axios、cheerio 和 puppeteer，可以快速实现爬虫功能。这些库极大地降低了开发复杂度，尤其是在处理 HTML 解析和动态页面时。

适用场景：如果优先考虑开发速度和生态丰富性，Node.js 更适合。

3. 并发与内存管理

Go：Go 的 goroutines 非常轻量，能够高效处理大量并发任务。同时，Go 的内存管理机制更加高效，适合大规模爬取任务。
Node.js：Node.js 的事件循环机制在一定规模的并发任务中表现良好，但在处理过多并发请求时，可能会面临内存压力和事件循环阻塞的问题。

适用场景：对于高并发和内存密集型任务，Go 更具优势。

4. 动态网页处理能力

Go：Go 在处理动态页面（如 JavaScript 渲染内容）时并不占优势。虽然可以使用 chromedp 等库实现浏览器自动化，但开发复杂度较高。
Node.js：Node.js 借助 puppeteer 或 playwright 等工具，可以轻松控制浏览器，处理动态内容和模拟用户行为。

适用场景：如果需要处理 JavaScript 渲染的动态内容，Node.js 是更好的选择。

总结

对比维度	Go	Node.js
性能	高性能，适合高并发任务	性能稍逊，适合 I/O 密集型任务
开发效率	语法简单，但生态不如 Node.js 丰富	丰富的库和工具，开发速度快
并发与内存管理	goroutines 高效，适合大规模爬取任务	事件循环机制，适合中小规模并发任务
动态网页处理	支持有限，开发复杂度高	借助工具轻松处理动态内容

选择 Go：适合高并发、大规模爬取、对动态内容处理需求较少的项目。
选择 Node.js：适合快速开发、处理动态网页、依赖丰富第三方库的项目。

根据项目需求权衡选择，才能更高效地完成爬虫开发任务

减少 Tailwind 中重复和冗长的 className

Wed, 23 Oct 2024 08:48:32 GMT

有几种方法可以减少 Tailwind 中重复和冗长的 className：

1. 使用 `@apply` 语法

在自定义的 CSS 文件中，使用 Tailwind 的 @apply 语法将常用的样式组合成一个自定义的类。例如：

/* styles.css */
.btn-primary {
  @apply bg-blue-500 text-white py-2 px-4 rounded;
}

然后在组件中使用：

<button className="btn-primary">Click me</button>

这样可以减少 JSX 文件中的 className 冗余。

2. 封装组件

将常用的样式封装成可复用的组件。例如，将按钮样式封装为一个 Button 组件：

const Button = ({ children, className, ...props }) => (
  <button
    className={`bg-blue-500 text-white py-2 px-4 rounded ${className}`}
    {...props}
  >
    {children}
  </button>
);

// 使用
<Button className="my-2">Click me</Button>;

通过这种方式，可以保持代码的简洁并提高复用性。

3. 使用 `clsx` 或 `classnames` 库

这些库可以帮助你有条件地组合多个 className，减少重复性。例如：

import clsx from "clsx";

const isActive = true;
const buttonClass = clsx("bg-blue-500 text-white py-2 px-4 rounded", {
  "opacity-50": !isActive,
});

<button className={buttonClass}>Click me</button>;

clsx 或 classnames 可以根据条件动态添加类名，避免硬编码所有的 className。

4. 使用 Tailwind 的 `theme` 配置

通过修改 Tailwind 配置文件（tailwind.config.js）来扩展主题或者自定义一些快捷类。例如，可以为常用的颜色或者尺寸创建更易读的别名：

// tailwind.config.js
module.exports = {
  theme: {
    extend: {
      colors: {
        primary: "#3490dc",
      },
    },
  },
};

然后在项目中直接使用自定义颜色：

<div className="bg-primary text-white">Hello, Tailwind!</div>

5. 结合 Tailwind 和 CSS-in-JS 库

可以搭配一些 CSS-in-JS 库（例如 styled-components 或 Emotion），结合使用 Tailwind 和自定义样式。这样可以在样式复用性和代码简洁性之间取得平衡。

通过这些方法，可以有效减少重复的 className，提高代码的可维护性和可读性。

Err Ossl Evp Unsupported

Tue, 22 Aug 2023 02:59:50 GMT

一个比较老的Vue项目，在启动时候，报错：

  opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
  library: 'digital envelope routines',
  reason: 'unsupported',
  code: 'ERR_OSSL_EVP_UNSUPPORTED'

问题原因是nodejs升级到17后，openssl3.0 对允许算法密钥大小增加了严格的限制，临时的解决办法是配置node_options.


# Windows 环境

$env:NODE_OPTIONS="--openssl-legacy-provider"
#or
set NODE_OPTIONS=--openssl-legacy-provider


# Linux or Mac
export NODE_OPTIONS=--openssl-legacy-provider

上述的方法是一次性的，也可以在package.json中对script进行修改，如


...
"serve" : "SET NODE_OPTIONS=--openssl-legacy-provider && vue-cli-service serve"
...

PHP代码质量工具之Laravel Pint

Thu, 10 Aug 2023 04:19:13 GMT

作为开发人员，我们有责任尽可能保持代码的最佳状态。这不仅有助于维护和扩展代码，还能避免出现错误。

在 PHP 中，有许多工具可以帮助我们实现高质量和无错误的代码，包括 PHP Mess detector、PHP CodeSniffer、PHPStan 和 Psalm。这些工具都很不错，但要集成到 Laravel 项目中并不容易。

后面我们会介绍五款专门用于帮助你及早捕捉错误、提高 Laravel 代码质量、确保编码风格统一的工具，让你在 Laravel 项目中轻松遵循最佳实践，现在我们先来说说 Laravel Pint。

我们还将介绍文本编辑器集成和使用这些工具的持续集成。

前提条件

本教程假定您已设置好 PHP 开发环境。本教程还假定您有 PHP 和 Laravel 方面的经验。

要充分利用本教程，我强烈建议您跟读本教程，以便亲自了解和测试这些工具是如何工作的。

为此，请克隆以下 repo：food-order-app-laravel-tdd：

git clone https://github.com/anchetaWern/food-order-app-laravel-tdd
cd food-order-app-laravel-tdd
git checkout tdd

接下来，将 .env.example 文件重命名为 .env，并用本地数据库密码更新 DB_PASSWORD。完成上述操作后，执行以下命令设置项目：

composer install
npm 安装
php artisan config:cache
php artisan migrate
php artisan db:seed

这样就能安装所有的 composer 和前端依赖项，更新配置，迁移数据库并为其播种。

我建议你安装 GitHub for desktop 或其他 Git 图形用户界面工具，这样你就能看到这些工具对你的代码做了什么。

什么是静态代码分析？

静态分析允许您在不运行代码的情况下检查代码是否存在问题。它基本上是读取代码、理解代码并将代码与特定规则进行比较，以验证代码的正确性。下面是一个例子：

function calculateSalary(int $days_worked, int $hours_worked_per_day): int
{
    ...
}
calculateSalary('20', 8)；

仅仅看一下，我们就已经知道代码会失败，因为我们为第一个参数提供的是字符串而不是整数。这就是静态代码分析的基本工作原理。不过，为了让静态代码分析更好地发挥作用，您需要在代码中使用类型（通过类型声明或 DocBlocks）。这将使检查更有效，有助于发现代码中的问题。

需要注意的是，静态分析器已经足够聪明，可以推断出大多数类型，因此在旧项目中添加类型并不是利用静态分析器的必要条件。

静态分析器会一次性扫描整个代码库。这意味着它们的工作环境与人类的代码审查环境不同。静态分析器知道不同文件之间是如何连接在一起的，这就是为什么它们能够发现代码审查中通常无法发现的问题。

你可能会想，既然我们已经使用了 PHPUnit 或 Pest 等工具来测试代码，为什么还需要静态分析器呢？这是因为这些工具不能立即使用。您必须先编写测试，然后才能使用它们来检测代码中的问题。通常情况下，运行测试也很耗时，因为它们需要执行你的代码。这就是静态分析和动态分析的主要区别。前者扫描代码，后者运行代码来检测问题。

使用代码分析工具有以下好处：

执行团队制定的编码标准。
确保遵循统一的编码风格。
及早发现潜在问题，这意味着向生产交付的错误更少。
提高代码质量。
检测安全漏洞。

Laravel pint

Laravel Pint 是检查代码质量的最新工具。从 Laravel 9 开始，创建新的 Laravel 应用程序时，Pint 会自动安装。它还自带检查的默认配置。这使得它很容易上手，因为你不需要做任何其他事情。唯一的缺点是它只支持 PHP 8 项目。

安装

如果你使用的是旧版本的 Laravel，可以用下面的命令安装 Pint：

composer require laravel/pint --dev

使用方法

要使用 Pint，请执行以下命令：

./vendor/bin/pint --test

这将显示 Pint 在你的代码中检测到的所有问题：

这样你就能知道它使用了哪些规则。输出结果并不容易阅读，因此建议设置 Pint 自动帮你解决问题：

./vendor/bin/pint 然后，你就可以在自己选择的 Git GUI 工具上查看输出结果，了解它做了哪些改动：

在上面的截图中，你可以看到它自动删除了未使用的导入，并加入了额外的空白来提高可读性。不过，它还会根据你的代码做更多改动。在提交之前，请务必查看它所做的更改。如果感觉有些地方不对，你可以直接还原更改，然后手动执行它建议的更改。

如果你没有安装 Git 图形用户界面工具，可以让 Pint 帮你打印它所做的修改：

./vendor/bin/pint -v 下面是输出示例：

Configuration

Pint 默认使用 laravel 预设规则，因此如果要使用其中的规则，无需做任何其他操作。您可以在项目目录根目录下创建 pint.json 文件来配置 Pint：

{ "preset": "laravel" } 其他支持的预设有 symfony 和 psr12。您可以这样更改

pint --preset psr12

如果不想使用这些预设，唯一的选择就是手工指定所有规则。Pint 建立在 PHP CS Fixer 之上，因此可以使用它的所有规则。您可以使用 PHP-CS-Fixer 配置器来挑选您自己的规则集。

由于规则很多，所以您很可能会以现有的规则集为基础。例如，有 CS Fixer 套件：

Here's a sample pint.json file:

{
    "preset": "laravel",
    "rules": {
        "simplified_null_return": true,
        "braces": false,
        "new_with_braces": {
            "anonymous_class": false,
            "named_class": false
        }
    }
}

请注意，您只能禁用现有预设中的规则。您不能指定一两个规则，然后指望 Pint 只检查这些规则。

有关 Pint 的更多信息，请参阅 Laravel 文档。

magento2中opensearch或mysql作为catalog search engine的区别

Wed, 26 Jul 2023 06:42:33 GMT

在Magento 2中，你可以使用OpenSearch或MySQL作为Catalog Search Engine。这两种搜索引擎在功能上有一些显著的不同：

性能和规模：如果你需要处理大量的数据并且需要更好的性能和扩展性，那么OpenSearch很可能是更好的选择。OpenSearch是一种基于分布式架构的搜索引擎，可以通过增加节点来扩展性能和容量。MySQL作为关系型数据库，性能和容量的扩展受到硬件和软件的限制。
搜索质量：OpenSearch使用先进的全文搜索算法，可以更好地处理模糊查询、拼写错误和语言处理等问题。相比之下，MySQL的搜索算法可能更加基础，但它也可以通过使用全文索引等技术来提高搜索质量。
集成和配置：集成OpenSearch可能需要更多的配置和工作，因为它是一个独立的搜索引擎。相比之下，Magento 2已经默认集成了MySQL，因此使用MySQL作为Catalog Search Engine可能需要更少的配置和工作。

总的来说，如果你需要更好的性能和扩展性，以及更高质量的搜索结果，那么OpenSearch可能是更好的选择。如果你正在寻找一种简单易用的搜索引擎，并且你已经熟悉了MySQL，那么使用MySQL作为Catalog Search Engine可能是更好的选择。

PHP 8.2：动态属性被弃用

Wed, 05 Jul 2023 09:16:27 GMT

在PHP类中，有可能动态地设置和检索未被声明的类属性。这些属性不遵守特定的（类似于类型化的属性），它需要使用get()和set()魔法方法来有效地防止或控制动态属性的设置和检索方式。

class User {
    private int $uid;
}

$user = new User();
$user->name = 'Foo';

在上面的片段中，User类没有声明一个名称为name的属性，但由于允许动态属性，PHP允许设置它。

虽然动态属性提供了创建类的灵活性，如没有严格的类声明的价值对象，但它为应用程序中潜在的错误和意外行为提供了可能性。例如，由于PHP默许所有的动态属性，设置属性的语句中的一个错别字可能会被忽略。

在 PHP 8.2 及以后的版本中，为未声明的类属性设置一个值是被废弃的，并且在应用程序执行过程中第一次设置该属性时，会发出废弃通知。

class User {
    private int $uid;
}

$user = new User();
$user->name = 'Foo';

Deprecated: Creation of dynamic property User::$name is deprecated in ... on line ...

从类中设置属性也会发出废弃通知：

class User {
    public function __construct() {
        $this->name = 'test';
    }
}

new User();

Deprecated: Creation of dynamic property User::$name is deprecated in ... on line ...

动态属性有合法的用例，比如从动态JSON响应中得到的值对象，或者允许任意值的配置对象。

理想情况下，类应该在类中声明动态属性以避免废弃通知。不需要用一个属性类型来声明该属性。

豁免的动态属性模式

这种废弃有三种例外情况。使用下面的方法之一可以避免废弃的通知。

参考： https://php.watch/versions/8.2/dynamic-properties-deprecated#exempt

GD库导致Magento2图片处理异常的问题处理

Mon, 19 Jun 2023 07:38:37 GMT

问题描述

部分产品图片无法正常加载，手动resize图片，报错。


bin/magento catalog:images:resize

# warning show:
# ... imagecreatefrompng(): gd-png: libpng warning: Interlace handling should be turned on when using png_read_image ...

查了一下这个问题，因该是 gd 库的bug 导致的报错，受系统环境制约，升级php版本及相关插件风险比较大，好再 Magento 提供了 GD2（默认）和 ImageMagic 两种库的选择，可以绕过该问题。

安装配置 imageMagic


yum install php-pear php-devel gcc
yum install ImageMagick ImageMagick-devel ImageMagick-perl
pecl install imagick

echo extension=imagick.so >> /etc/php.ini
systemctl restart php-fpm.service

修改默认Adapter


# show default adapter
bin/magento config:show dev/image/default_adapter
GD2
# set imagick as default adapter
bin/magento config:set dev/image/default_adapter IMAGEMAGICK

然后刷新缓存，重新resize，一切正常。

brew切换php版本不生效的改进方案

Tue, 23 May 2023 08:10:15 GMT

mac环境随时随地方便的切换php版本，前提如下：

Mac 环境, zsh为默认shell
安装了brew
通过brew 安装了多个版本的php

基本方式

举例，从php.7.4切换到php8.1

brew unlink php7.4 && brew link --overwrite --force php@8.1

到这一步，如果运行 php -v ，那么版本还是7.4 ，因为还需手动更新.zshrc文件中的PATH路径，以确保使用正确的PHP版本。

vim ~/.zshrc

#注释掉下面两行
export PATH="/usr/local/opt/php@7.4/bin:$PATH"
export PATH="/usr/local/opt/php@7.4/sbin:$PATH"

#手动添加如下两行
export PATH="/usr/local/opt/php@8.1/bin:$PATH"
export PATH="/usr/local/opt/php@8.1/sbin:$PATH"

#保存后运行下面命令之使生效
source ~/.zshrc

改进方式

将上面提到的命令写成bash脚本，一次运行。


#!/bin/zsh
if [ "$1" = "7.4" ]; then
    brew unlink php@8.1 && brew link --overwrite --force php@7.4
    sed -i '' '/php@[0-9\.]*\//d' ~/.zshrc
    echo 'export PATH="/usr/local/opt/php@7.4/bin:$PATH"' >> ~/.zshrc
    echo 'export PATH="/usr/local/opt/php@7.4/sbin:$PATH"' >> ~/.zshrc
elif [ "$1" = "8.1" ]; then
    brew unlink php@7.4 && brew link --overwrite --force php@8.1
    sed -i '' '/php@[0-9\.]*\//d' ~/.zshrc
    echo 'export PATH="/usr/local/opt/php@8.1/bin:$PATH"' >> ~/.zshrc
    echo 'export PATH="/usr/local/opt/php@8.1/sbin:$PATH"' >> ~/.zshrc
else
    echo "Invalid argument. Please enter either '7.4' or '8.1'."
    exit 1
fi

source ~/.zshrc

文件需要保存为.zsh后缀，首行声明 #!/bin/zsh , 否则会报错：Oh My Zsh can't be loaded from: sh. You need to run zsh instead. 因为脚本在Bash中运行，而不是在zsh中运行。解决办法是将脚本转换为zsh脚本，将脚本的文件扩展名从.sh更改为.zsh，然后在脚本的开头添加以下行：#!/usr/bin/env zsh；或者脚本的开头添加以下行：#!/bin/zsh

然后运行下面的命令执行：


./switch-php.zsh 7.4
#OR
./switch-php.zsh 8.1

然而，脚本中的最后一行似乎没有生效。原因是在脚本中执行source ~/.zshrc，则会在子shell中运行，该子shell无法影响父shell的环境。因此，即使在脚本中添加了该行，也不会影响当前的终端会话。

为了解决这个问题，可以将脚本转换为函数，并将其添加到您的.zshrc文件中。这样，每次打开终端时，都会将该函数加载到终端会话中，并且可以在当前终端会话中直接调用该函数来切换PHP版本。

因为脚本会更改 .zshrc 文件自身，为了防止函数本身被修改，我们将函数放在另一个文件中，然后从.zshrc中引入。

新建文件custom.zsh

#!/bin/zsh
function switch-php() {
if [ "$1" = "7.4" ]; then

    brew unlink php@8.1 && brew link --overwrite --force php@7.4
    sed -i '' '/php@[0-9\.]*\//d' ~/.zshrc
    echo 'export PATH="/usr/local/opt/php@7.4/bin:$PATH"' >> ~/.zshrc
    echo 'export PATH="/usr/local/opt/php@7.4/sbin:$PATH"' >> ~/.zshrc
elif [ "$1" = "8.1" ]; then
    brew unlink php@7.4 && brew link --overwrite --force php@8.1
    sed -i '' '/php@[0-9\.]*\//d' ~/.zshrc
    echo 'export PATH="/usr/local/opt/php@8.1/bin:$PATH"' >> ~/.zshrc
    echo 'export PATH="/usr/local/opt/php@8.1/sbin:$PATH"' >> ~/.zshrc
else
    echo "Invalid argument. Please enter either '7.4' or '8.1'."
    exit 1
fi

source ~/.zshrc

然后在在.zshrc 尾部加入一行，引入该文件

source ~/custom.zsh

保存后执行 source ~/.zshrc. 使修改生效，然后就可以随时随地一条命令切换php版本了

switch-php 7.4
#or
switch-php 8.1

php7.4 与 php8差异

Mon, 22 May 2023 15:17:28 GMT

PHP 8.0 是 PHP 7.x 系列的下一个主要版本，与 PHP 7.4 相比有一些重大的变化和改进。以下是 PHP 8.0 相对于 PHP 7.4 的一些重要的变化和改进：

JIT 编译器：PHP 8.0 引入了一个全新的 JIT 编译器，可以提高代码的执行速度，尤其是在大型应用程序中。
新的语言特性：PHP 8.0 引入了一些新的语言特性，例如命名参数、联合类型、match 表达式等，可以提高代码的可读性和可维护性。
函数和类的改进：PHP 8.0 对一些函数和类进行了改进，例如 str_contains()、str_starts_with()、str_ends_with() 函数，以及 DateTime 类等。
错误处理的改进：PHP 8.0 对错误处理进行了改进，例如引入了新的 Throwable 接口、Union Types 等，可以提高代码的健壮性和可靠性。
移除了一些废弃的特性：PHP 8.0 移除了一些废弃的特性，例如 magic_quotes_gpc、realpath_cache_size 等，可以提高代码的安全性和稳定性。

总的来说，PHP 8.0 相对于 PHP 7.4 有一些重大的变化和改进，尤其是 JIT 编译器和新的语言特性等，可以提高代码的执行速度和可读性。但是，这些变化和改进也可能导致一些不兼容性问题，因此在升级到 PHP 8.0 之前，需要仔细评估其对项目的影响，并进行充分测试。

Javascript Fetch Note

Mon, 08 May 2023 09:40:09 GMT

An Example about Fetch

fetch("https://api.example.com/data", {
  method: "POST", // 请求方法
  headers: {
    "Content-Type": "application/json", // 请求头中的 Content-Type
  },
  body: JSON.stringify({
    // 请求体中的数据
    name: "John Doe",
    age: 30,
  }),
})
  .then((response) => {
    if (response.ok) {
      // 判断响应是否成功
      return response.json(); // 将响应转换为 JSON 格式
    } else {
      throw new Error("Network response was not ok."); // 抛出异常
    }
  })
  .then((data) => {
    console.log(data); // 处理 JSON 格式的响应数据
  })
  .catch((error) => {
    console.error("There was a problem with the fetch operation:", error); // 处理异常
  });

fetch 默认是异步执行的。当你调用 fetch 函数时，它会立即返回一个 Promise 对象，然后在后台发起网络请求。一旦请求完成，Promise 对象就会被解析为一个 Response 对象，然后你可以使用 then() 方法来获取响应数据。

由于 fetch 是异步执行的，它不会阻塞 JavaScript 主线程。这意味着你可以在发送请求时继续执行其他的 JavaScript 代码，不必等待网络请求完成。这种异步执行的方式可以提高应用程序的性能和响应速度。

如果你需要使用 fetch 函数来进行同步请求，可以使用 async/await 或者使用同步的 XMLHttpRequest 对象。但是，这种同步方式可能会降低应用程序的性能和响应速度，因此不建议在大多数情况下使用。

以root用户运行php-fpm

Sat, 06 May 2023 09:50:53 GMT

在开发环境中，为了避免文件权限带来的问题，可以将php-fpm的运行用户设为root.

但在默认情况下，直接修改php的运行用户为root，重启php-fpm进程后会报错

ERROR: [pool www] please specify user and group other than root
[26-Jun-2014 00:39:07] ERROR: FPM initialization failed

通过查看php-fpm的文档得知，如果要以root用户运行，需要加上特定参数

# php-fpm --help
...
 -R, --allow-to-run-as-root
               Allow pool to run as root (disabled by default)

如何添加这一参数：

找到 php-fpm.service , 可以使用命令
```
find / -name php-fpm.service
```

添加参数

ExecStart=/usr/sbin/php-fpm --nodaemonize -R

重启php-fpm.
```
systemctl restart php-fpm
```

注意，切勿在正式环境中使用root来运行php-fpm

Warning: php-fpm.service changed on disk. Run 'systemctl daemon-reload' to reload units. 修改后如有这个警告，执行即可。

magento2中Index Management两种模式的差异

Fri, 28 Apr 2023 14:08:59 GMT

Magento 2的Index Management有两种模式：Update on Save和Update by Schedule。它们的区别如下：

Update on Save：这是Magento 2的默认模式。在此模式下，当商品、类别、客户等数据发生更改时，索引会立即更新。这意味着在每次保存数据时都会更新索引，因此可以确保索引始终是最新的。但是，这种模式可能会影响性能，因为每次保存数据时都会触发索引更新。
Update by Schedule：在此模式下，索引更新是按计划进行的。您可以在Magento 2后台的“索引管理”中配置索引更新计划，例如每小时、每天或每周更新一次。这种模式可以减少索引更新对性能的影响，因为索引更新不会在每次保存数据时触发。但是，这种模式可能会导致索引不是最新的，因为在计划更新之前，数据可能已经发生了更改。

因此，选择适当的索引更新模式取决于您的应用程序的需求。如果您需要确保索引始终是最新的，并且可以容忍性能影响，则可以选择Update on Save模式。如果您更关注性能，并且可以容忍索引不是最新的，则可以选择Update by Schedule模式。

Git游离状态commit内容的找回

Tue, 11 Apr 2023 10:15:26 GMT

情况，在一个游离的分支上提交了commit，然后checkout到某一分支，发现commit的内容找不到了。

解决办法：

1、通过 git reflog 查看所有分支的操作记录，找到那个commit id

2、切换到目标分支，例如 git checkout developer

3、通过 git cherry-pick {commit_id}把那个游离的commit 内容重新提交到当前分支上

记录一下这两个命令：

git reflog是Git操作的一道安全保障，它能够记录几乎所有本地仓库的改变，包括所有分支的commit提交，以及已经被删除的commit
git cherry-pick <commitHash> 将指定的commit提交到当前分支。（与merge类似，merge是合并一个分支的所有变更，cherry-pick 更加精确）

REMOTE HOST IDENTIFICATION的错误解决

Fri, 31 Mar 2023 13:25:14 GMT

通过 ssh 连接远程主机的时候，经常会碰到如下错误，这通常是由于服务器IP\用户名等信息变更导致的

[root@localhost ~]# ssh 192.168.1.x
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
...
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:33
RSA host key for 192.168.1.x has changed and you have requested strict checking.
Host key verification failed.

有两种解决办法

直接删除下面的文件，或者删除know_hosts中的对应192.168.1.x的连接


~/.ssh/known_hosts

使用 ssh-keygen


ssh-keygen -R 192.168.1.x

ubuntu环境下彻底卸载docker

Fri, 31 Mar 2023 13:25:14 GMT

安装docker的时候，建议直接去docker的官网看文档，其他的博客或者工具安装，容易出现纰漏，导致后面报错。如果已经安装且出现了不知道如何应对的问题，那么就需要彻底删除掉之前的安装。

Ubuntu系统下彻底删掉docker的步骤

dpkg -l | grep -i docker

确定安装了什么包


sudo apt-get purge -y docker-engine docker docker.io docker-ce docker-ce-cli docker-compose-plugin
sudo apt-get autoremove -y --purge docker-engine docker docker.io docker-ce docker-compose-plugin

上述命令不会删除主机上的镜像、容器、卷或用户创建的配置文件。如果你想删除所有的镜像、容器和卷，请执行以下命令：

sudo rm -rf /var/lib/docker /etc/docker
sudo rm /etc/apparmor.d/docker
sudo groupdel docker
sudo rm -rf /var/run/docker.sock

Docker 安装文档：https://docs.docker.com/engine/install/

laravel 和 lumen 两个框架的差异是什么

Fri, 31 Mar 2023 02:08:21 GMT

Laravel 和 Lumen 都是由 Taylor Otwell 开发的 PHP Web 开发框架，它们有很多相似之处，但也有一些明显的差异。

以下是 Laravel 和 Lumen 之间的一些主要差异：

框架大小：Lumen 框架比 Laravel 框架更轻量级。Lumen 框架具有更小的内存占用和更快的启动时间，这使得它成为构建小型微服务和 API 的理想选择。
功能：Lumen 框架的功能比 Laravel 框架更加简洁，去除了一些不必要的组件，比如 Session 和 Cookie 管理等。Lumen 框架的主要重点是快速构建 Web 应用程序和 RESTful API。
性能：由于 Lumen 框架比 Laravel 框架更轻量级，因此它在处理大量请求时表现更佳。Lumen 框架也支持更多的缓存驱动器和队列驱动器，这使得它在高并发环境中表现更加出色。
使用场景：Lumen 框架适用于构建小型 Web 应用程序和 RESTful API，而 Laravel 框架则适用于构建大型 Web 应用程序和企业级应用程序。

总之，Lumen 框架是 Laravel 框架的轻量级版本，它们在设计和实现上都有很多相似之处，但是在应用场景和功能方面有一些显著的不同。

Intel Standard Manageability主要功能及试用

Wed, 22 Mar 2023 09:05:52 GMT

Intel vPro® 除了提供完整 Intel AMT manageability 之外，还提供 Intel Standard Manageability(英特尔标准可管理性模式)，是 AMT 功能的一个子集。

Intel Standard Manageability 是与Intel AMT 5.0版一起推出的，支持以下 AMT 功能的子集。

Hardware Inventory 硬件资源管理，查询客户机可用的硬件，如BIOS功能、CPU、内存、附加卡等
Boot Control 启动管理
Power State Management 电源状态管理
Redirection ， Serial Over LAN and Storage Redirection (USB-R or IDE-R) over TCP。
Alarm Clock 定时唤醒
Agent Presence 可以远程配置的“看门狗”程序
Access Monitor 用户活动监测
System Defense Filters 远程配置宿主机的网络过滤

参考：https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm?turl=WordDocuments%2Fsupportforotherintelplatforms.htm

以下是几个功能的使用截图，所使用的软件是MeshCommander，这套软件不久前英特尔已经放弃做支持，但是已经迭代和很久，功能比较全也比较稳定。

MeshCommander : https://www.meshcommander.com/meshcommander

Redirection 串口设备重定向

简单的讲，可以操作BIOS、挂载镜像文件用来引导远程系统，下面是通过 Serial-Over-Lan看到的BIOS界面，这个界面是以字符的形式显示的，控制端默认的格式和换行有问题，试着调整了一下还是这个样子，这个使用的工具有关。

下面是使用Serial挂载ISO或者 IMG文件的操作

这个实际使用的时候速度比较慢，我实际试了几次，挂载，读取，设置系统启动引导都没问题，但是速度特别慢，大概在 10Mbs 以下，用一个4G的镜像来远程安装系统，预计得几个小时。

这个速度慢的问题在github上也看了，目前应该就是这样，有人给出的建议是使用小的镜像文件引导，然后再通过网络下载的方式。

关于这个速度的讨论：https://github.com/Ylianst/MeshCentral/issues/951 有人提到了这个工具 https://netboot.xyz/docs/

Agent Presence

Agent Presence Hight-Level-API 特性包含两个主要接口

一组接口提供从远程计算机执行的API功能
一组本地AMT宿主机上的本地主机调用的API

下面是从远程控制端添加看门狗的操作，添加完这个看门狗，还需要从本地宿主机调用接口来完成和具体程序的关联等操作。

如何在设备端本地调用接口，完成这个看门狗的配置，目前还没找到方便的测试方法。

参考 https://software.intel.com/sites/manageability/HLAPI_Documentation/default.htm?turl=Documents%2Fagentpresence.htm

System Defense

可以从控制端来配置一个网络包的过滤器，可以对数据包进行允许，丢弃，以及限速的操作。

Alarm Clock 定时唤醒

这个功能比较简单，可以从远程控制端来配置定时，或者定期唤醒设备。使用场景的话，比如每天7点定时开机执行任务，任务完成自动关机。

Access Monitor

这个功能也叫做 Audit Log ，主要记录的是 AMT 相关的一些操作，如下图所示：

参考：https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm?turl=WordDocuments%2Faccessmonitor.htm

docker 中使用的 kong 是干什么的

Tue, 21 Mar 2023 09:15:21 GMT

Kong 是一个用于构建微服务架构的开源 API 网关和微服务管理平台。在 Docker 中使用 Kong 通常是为了在微服务架构中实现 API 管理和微服务发现。

Kong 可以作为一个 API 网关，代理客户端请求并将请求路由到对应的后端微服务。Kong 还提供了丰富的插件，可以对请求进行身份验证、流量控制、日志记录、监控等处理。

在 Docker 中，使用 Kong 可以快速搭建一个高效、可扩展的 API 网关，并且可以方便地部署和管理。Kong 还可以与 Docker 中的其它容器化应用程序无缝集成，实现完整的微服务架构。

下面是几个使用 Docker 中 Kong 实现微服务架构的例子：

假设你正在构建一个电子商务网站，并使用多个微服务来处理订单、库存、支付和用户管理等任务。你可以使用 Kong 作为 API 网关来统一管理这些微服务，并为每个微服务配置不同的 API 策略和安全机制。

假设你正在构建一个面向企业的 SaaS 应用程序，该应用程序由多个独立的微服务组成，包括用户管理、权限控制、数据分析和营销自动化等功能。你可以使用 Kong 来将这些微服务整合在一起，并为每个微服务提供统一的入口点和安全机制。

假设你正在构建一个在线教育平台，并使用多个微服务来处理课程管理、学生管理、支付和证书颁发等任务。你可以使用 Kong 作为 API 网关来为每个微服务提供独立的 API 策略和流量控制，以确保平台的安全和稳定性。

记第n次开博

Wed, 15 Mar 2023 15:06:05 GMT

博客关了开，开了关，不记得这是第几次了。

hexo的火还没熄，新的轮子hugo又开始了，一个go写的博客工具，可以很方便的整理和发布markdown格式的笔记，那就试试，来吧。

最近做的事情比较杂，东研究一下，西研究一下，记录一下放这里也许可以帮到别人。