CSS break-word导致的诡异换行问题排查记
记录一次由CSS break-word属性引发的诡异渲染问题,公式莫名其妙换行,原来问题出在DOM结构层级上
记录一次由CSS break-word属性引发的诡异渲染问题,公式莫名其妙换行,原来问题出在DOM结构层级上
最近在用 Claude Code,换了成本更低的Codex,记录一下配置过程。方便以后查看,快速配置。
配置文件位置:
~/.codex/config.tomlC:\Users\你的用户名\.codex\config.toml直接上配置:
1 | model_provider = "codex" |
几个关键配置:
model_provider: 设置成 "codex" 就行model: 用的模型,这里是 gpt-4.1-minimodel_reasoning_effort: 推理强度,low/medium/high 三档,medium 够用disable_response_storage: 不保存历史记录,开启更安全base_url: API 地址,换成你自己的env_key: 环境变量名,密钥别直接写配置文件里找到配置文件,把上面的配置复制进去,改一下 base_url 和 model。
macOS/Linux 在 ~/.zshrc 或 ~/.bashrc 加一行:
1 | export K_CODEX="your-api-key-here" |
然后 source ~/.zshrc 生效。
Windows PowerShell 执行:
1 | [System.Environment]::SetEnvironmentVariable('K_CODEX', 'your-api-key-here', 'User') |
重启终端就能用了。
在使用 React Hooks 开发时,useEffect 的依赖数组管理是一个常见的痛点。很多开发者遇到过这样的困扰:依赖项过多导致 Effect 频繁执行,或者为了图方便直接禁用 ESLint 规则,最终引发难以调试的 bug。
本文将从 React 官方文档和源码层面深入探讨如何正确管理 Effect 依赖,帮助你写出更高效、更可维护的 React 代码。
React 官方文档明确指出:依赖应该与代码匹配。这意味着 Effect 中使用的每一个响应式值(props、state)都必须出现在依赖数组中。
React 的 ESLint 插件 eslint-plugin-react-hooks 会自动检查这一规则,确保你的依赖声明是完整的。
永远不要用注释禁用依赖检查:
1 | // ❌ 危险做法 |
React 文档强调:应该把依赖检查错误当作编译错误来对待。忽略它会导致微妙且难以诊断的 bug。
如果某段代码应该响应特定的用户交互而非响应式变化,应该放在事件处理器中:
1 | // ❌ 不好的做法 |
当一个 Effect 同步多个不相关的过程时,应该拆分成多个 Effect:
1 | // ❌ 不好的做法 |
通过传递更新函数而非直接读取 state,可以移除状态依赖:
1 | // ❌ 不好的做法 |
useEffectEvent 允许你提取非响应式逻辑,读取最新值而不触发重新同步:
1 | // ✅ 使用 Effect Event |
注意: useEffectEvent 目前仍是实验性 API,尚未包含在稳定版 React 中。
对象和函数在每次渲染时都是新的引用,会导致不必要的重新执行:
1 | // ❌ 不好的做法 |
当接收对象 props 时,解构出原始值作为依赖:
1 | // ❌ 不好的做法 |
让我们深入 React 源码,看看 useState 背后的实现机制。以下代码来自 React v19.1.1 的 ReactFiberHooks.js:
1 | function mountStateImpl<S>(initialState: (() => S) | S): Hook { |
惰性初始化支持:当 initialState 是函数时,React 会执行它来获取初始值。这就是为什么我们可以写 useState(() => expensiveComputation())。
严格模式双重调用:在开发模式的严格模式下,初始化函数会被调用两次。这是 React 的一个特性,用于帮助检测不纯的初始化函数中的副作用。
状态存储:初始值会同时存储在 memoizedState(当前状态)和 baseState(基础状态)中。这是 React 实现状态更新和并发渲染的基础。
理解 useState 的实现有助于我们更好地管理 Effect 依赖:
1 | // 为什么惰性初始化不需要依赖 |
让我们通过一个完整的例子整合这些最佳实践:
1 | function ChatRoom({ roomId, theme, currentUser }) { |
roomId,只在切换房间时重新连接theme 和 currentUser 变化不会导致重新连接setMessages(msgs => [...msgs, message]) 避免依赖 messagesReact DevTools 的 Profiler 可以帮你识别哪些组件因为 Effect 重新渲染:
在开发环境添加日志帮助理解 Effect 执行时机:
1 | useEffect(() => { |
确保在项目中启用并配置该插件:
1 | { |
1 | // ❌ 错误理解 |
依赖少不是目标,准确的依赖才是目标。不要为了减少依赖而牺牲正确性。
1 | // ❌ 这是技术债务 |
这会在未来引发难以追踪的 bug,绝对不要这样做。
Effect 依赖管理是 React Hooks 开发中的重要技能。关键要点:
通过遵循这些最佳实践,你可以写出更高效、更易维护的 React 代码,避免常见的 Effect 依赖陷阱。
哭哭,不知道咋了。自从来了武汉,经常发烧头疼。呕吐。
可能是因为到年纪了?BMI超重了?不知道还是因为打了三针科兴。
今天又发烧了37.5度。
早上起床吃了布洛芬,一觉睡到了现在晚上七点多这个点儿。
催了沙雕对象好几次做饭,一直让我等会儿。快饿哭了。头疼,浑身都疼真的就想躺在床上啥也不想动。
作为一个使用 Hexo 搭建博客的开发者,每次写完文章都要手动执行
1 | hexo clean && hexo generate && hexo deploy |
这一系列命令是不是很麻烦?今天就教大家如何使用 GitHub Actions 实现 Hexo 博客的自动化部署。
GitHub Actions 是 GitHub 提供的持续集成和持续部署(CI/CD)服务。它可以在代码仓库发生特定事件时自动执行预定义的工作流程,比如代码提交、PR 创建等。
我们的方案是:
在 Hexo 博客源码仓库根目录下创建 .github/workflows/deploy.yml 文件:
1 | name: Deploy Hexo to GitHub Pages |
在上述配置中,工作流会在以下情况触发:
main 分支source/_posts/**、source/**、themes/** 目录下的文件_config*.yml 或 package.jsonworkflow_dispatch)Hexo Blog Deploy(或其他描述)Settings → Secrets and variables → ActionsDEPLOY_TOKEN将 deploy.yml 中的 external_repository 改为你的 GitHub Pages 仓库名:
1 | external_repository: 你的用户名/你的用户名.github.io |
配置完成后,使用流程变得非常简单:
source/_posts 目录下创建或修改 Markdown 文章1 | git add . |
Actions 页面使用 GitHub Actions 自动部署有以下优势:
A: 查看 Actions 页面的详细日志,常见问题包括:
A: 可以,在 source 目录下添加 CNAME 文件,内容为你的域名即可。
A: 可以使用 npm ci 代替 npm install,并启用 npm 缓存(配置中已包含)。
通过 GitHub Actions,我们实现了 Hexo 博客的全自动部署。从此以后,写博客只需要专注于内容创作,提交代码后坐等自动部署完成即可。