Posts

“飞书 CLI 现已面向所有用户开源。（真开源，不是要登记还要审核那种） 无论你想让 Claude Code、Codex 还是其他 Agent 直接操作飞书，或是希望围绕飞书构建新一代自动化工作流，欢迎使用” 中午正在开着车，等红灯的时候瞄了眼手机，就看到了上面的消息。第一反应是 “wow 一定要试试”，因为我现在也是高度的 Lark 使用用户！ 跑去仓库看了一眼，果然是新鲜出炉的，代码是2小时前提交的。 字节真棒啊，周六还在干活 — 现在大厂都足够拼搏的！ 一句话安装 安装特别简单，直接对着我的 Codex 口喷： 帮我装一下所有的东西：https://github.com/larksuite/cli/blob/main/README.zh.md 上面这个 Prompt 也是卡兹哥的文章上看到的，它是在 Claude Code 上跑的，我在 Codex 上跑了一遍也顺利的完成了安装。 而且建议使用上面的 Prompt 安装，不要直接说安装 飞书 Cli，这样有可能不安装 Skills。 网页授权 飞书的 Cli 需要去读取个人用户数据，所以安装完的第一个步骤就是授权登录。 让 Codex 继续完成登录即可。然后就会给你一个二维码链接，复制到浏览器里面自己手动配置一下。 点击授权即可完成授权登录。 功能 基本上涵盖了我们日常使用的功能，对于我来说最重要的是多维表格和文档功能，以后的技术架构、需求评审等文档可以直接用 AI 生成然后帮我上传到 Lark 上。 安全与风险 过于由于数据不互通，Agent 能力不能好好释放，现在有了 Cli，Agent 能够拿到这些数据，但也伴随着风险。 开放是一把双刃剑，AI 的 prompt 注入导致的数据泄漏案例不是1个2个了，因此建议还是开最小的权限（特别是数据敏感型公司）。 另外模型也有幻觉，现在 Agent 可以操作飞书聊天，但如果模型出 bug 了，在群里发疯会带来负面影响。因此当下建议飞书机器人作为私人对话助手使用。 MCP已死？CLI永生 Cli 会代替 Mcp 吗？ ...

最近发现了一款很好用的 Terminal，非常适合 AI Coding 工具，之前我一直用 iTerm 配合 zsh 来操作命令行，但它在 node 服务开的多的情况下会变卡。 以下内容原文出处来源于 X 上的 @BruceBlue，写的非常细致， respect。 你是不是也遇到过这些崩溃时刻： 终端卡得像老牛拉车？ Claude写代码时输出一堆文字看不清？ 想左右分屏（左边让Claude写代码、右边debug） 却不知道怎么加屏幕？ 配置一改就弹窗报错？ 慌！ Ghostty就是为你准备的！ 它像一个调皮的小鬼，跑得飞快、长得漂亮，还天生和Claude是好搭档。 这篇全新入门文章，我把所有坑都踩过一遍，用最简单的话 + 手把手截图 + 基础命令教你。 读完5分钟，你就能： 打开Ghostty就自动进Claude Cmd + D 一键左右添加屏幕 Cmd + Shift + Enter 一键放大Claude输出 配上彩虹状态栏 + 快乐现场 准备好了吗？我们一起“鬼混”开发吧！🚀 Ghostty官网：https://ghostty.org/ Ghostty由HashiCorp联合创始人 @mitchellh 从2021年开始当“副业”鼓捣，用Zig语言写的核心。2024年底正式开源。 它的三大好处（小白最爱）： 超级快：GPU加速（macOS用Metal），Claude输出再长也不卡，滚动丝滑像丝绸。 超级漂亮：原生macOS界面，支持透明毛玻璃、Catppuccin紫色主题、完美连字字体，看代码眼睛不累。 超级好用：支持Kitty图形协议（Claude让你画图？图片直接在终端显示！）、Quick Terminal下拉幽灵、一键分屏、永久保存布局。 一句话总结：Ghostty不逼你“要么快要么丑”，它全都要！ 免费开源，还在狂迭代。 第一步：安装Ghostty（超级简单，3分钟） 在你的Mac终端（或者已经打开的Ghostty）里敲下面这行，回车： brew install --cask ghostty 安装完直接在Spotlight搜索 Ghostty 打开它。 第一次打开可能会出现两个窗口（一个是下拉的幽灵终端），别担心，我们马上解决！ 基础命令： 想随时打开Ghostty？按 Command + 空格，输入 “Ghostty” 回车就行。 ...

Node.js 框架在 2024 年呈现出多样化的发展态势，其中 Elysia、Hono、Nest 和 Encore 等框架备受关注。本文尝试记录这些框架的优势、劣势以及适用场景，帮助日后技术选型。 框架特性概述 根据轻量级到功能丰富程度，这些框架的排序如下： 这并不意味着轻量级框架不好，而是取决于项目需求。Hono 的轻量级特性使其非常适合部署到 Cloudflare Workers，而 Encore.ts 则内置了许多功能，如自动追踪和本地基础设施。 Encore.ts 仓库地址：https://github.com/encoredev/encore Encore.ts 是一个开源框架，旨在简化使用 TypeScript 构建健壮且类型安全的后端应用。它内置了丰富的工具，可提升开发体验，在性能方面表现卓越，是本次比较中速度最快的框架。 Encore 具有内置的请求验证功能，使用常规 TypeScript 定义的请求和响应类型可在编译和运行时验证请求。与其他框架不同，实际验证在 Rust 中完成，而非 JavaScript，这使其验证速度极快。 Encore 便于创建和调用服务，从代码角度看，服务就像存储库中的普通文件夹，调用服务端点如同调用普通函数。其神奇之处在于，这些函数调用在底层会转换为实际的 HTTP 调用。部署时，你甚至可以选择将服务部署到不同实例，如 Kubernetes 集群，同时保持所有服务代码在同一存储库中。 Encore 还带有内置的开发仪表板，启动应用后，可通过localhost:9400访问。在这里，你可以像使用 Postman 一样调用端点，每次调用都会生成一个跟踪，用于检查 API 请求、数据库调用和发布 / 订阅消息。本地开发仪表板还包括自动 API 文档和系统的最新架构图。值得一提的是，尽管 Encore 功能丰富，但它没有任何 npm 依赖项。 Hono 仓库地址：https://github.com/honojs/hono Hono 由 Yusuke Wada 创建，始于 2021 年，旨在解决 Node.js 框架在 Cloudflare Workers 上运行不佳的问题。此后，Hono 增加了对 Node.js、Bun 和 Deno 等多种运行时的支持。 import { Hono } from 'hono' const app = new Hono() app.get('/', (c) => c.text('Hono!')) export default app Hono 非常小巧，hono/tiny预设版本不到 13KB，非常适合部署到 Cloudflare Workers，并且它也没有 NPM 依赖项，令人印象深刻！ ...

作为前端开发如何知道用户在页面上操作行为是否符合预期？用户点击某个按钮或使用某个功能异常时我们能否快速定位？上线的功能是否会导致线上 bug? 曾经一度这些问题深深困扰我们，作为一个没有测试团队的自研型产品研发团队，我们的上线依靠发布前走查关键测试用例来避免线上问题，但这种方式耗时耗力不说，因为人为测试总有遗漏的地方，也不能保证 100% 稳定可靠，只能保证核心功能不出问题。 因此，我们需要一套可靠的前端日志系统，来帮助我们实时观测用户使用数据及线上异常情况，另可以快速定位问题，不至于出现问题还需要跟用户远程复现（效率太低）。我们把技术方案瞄准为 ELK 套件 架构来帮助解决以下问题： 全链路问题排查，通过日志搜索查询用户的入参出参报错等全链路信息、按时间序列分析或还原用户的操作行为排查问题 数据统计分析，通过日志数据可以灵活的自定义统计分析，如系统的UV、PV、用户行为分析、接口调用量、接口响应速度、异常报错统计等等 自定义上报，因前端无法直接打印日志到服务器或数据库中，需要满足前端的一些浏览点击、资源加载、js报错、自定义上报等场景日志等需求 智能归因分析，监控报警需要做好报警的收敛和治理，如何使用AIGC技术去做智能化的报警分析是非常值得探索的方向 持久化存储，一些数据统计分析需求需要部分日志持久化存储，自行控制日志的生命周期。 系统架构 整体的系统架构采用的就是经典的ELK架构，即 Elasticsearch + Logstash + Kibana 的组合，同时引入了filebeat作为轻量化的nginx日志采集的组件。 整体的系统架构如下： 整体的方案是借助ELK架构去收集前端服务器的nginx日志及后端日志进行结构化存储到ES集群，通过ES强大的全文搜索能力及Kibana组件数据可视化能力进行日志的搜索和分析。 nginx服务器 前端服务主要使用的就是nginx进行页面部署和一些接口的代理转发，nginx日志本身就会记录用户所有的接口请求，但是nginx日志默认是不能记录到请求的响应值的和做一些前端自定义上报日志记录的，所以我们需要对nginx进行一些配置个改造。 为了能打印到接口的响应值，我们引入了OpenResty替代nginx，使用OpenResty结合lua脚本就可以非常简单的获取到接口的返回值并打印到nginx的access日志里，主要是获取接口的返回buffered并使用zlib库进行解码。 下面是nginx配置文件的简单示例，可以根据自己业务需求获取及打印所需字段： log_format main escape=json '{"user":"$user","uri":"$uri","$http_appkey","req_body","resp_body":"$resp_body","timestamp":"$time_iso8601","ups_res_time":"$upstream_response_time"}'; location /api/ { proxy_pass http://api.xxxx.jd.com/; body_filter_by_lua ' local zlib = require("zlib") if type(ngx.arg[1]) == "string" then local resp_body = string.sub(ngx.arg[1], 1, 5000000) ngx.ctx.buffered = (ngx.ctx.buffered or "") .. resp_body if ngx.arg[2] then local inflate = zlib.inflate() local ok, decoded = pcall(inflate, ngx.ctx.buffered) ngx.var.resp_body = ok and decoded or ngx.ctx.buffered end else ngx.var.resp_body = "" end '; } 为了实现前端可以自定义上报一些报警日志到nginx，我们采用的是构造一些约定的请求和对应的nginx日志字段，前段需要上报日志的时候去发起请求并把上报内容放到请求体，nginx端将其写入nginx日志即可完成对应的流程。 ...

我所在的团队几年前开始实现一款基于 URL 拼接方式的实时合图能力，应用场景则是用在广告图千人千面的场景下，很多 App 首页都有 banner 广告位，为了最大程度提升广告的效率，广告算法推荐需要实现了一套通过不同的 sku + 不同的文案 + 不同的模版，然后生成一张广告图的技术方案。 这套技术方案抛开推荐算法不提，最为重要的是如何在用户打开 App 的瞬间能够合成出广告图，而我当时主要负责服务端广告图合成技术。于是就有了本文的技术方案- 毫秒级广告图合成。 URL 设计 对于图片服务器而言，要求业务逻辑尽量简单，最大化利用图片路径来做参数传递，当浏览器打开一个图片资源时，源服务器可以快速找到所在服务器分片并迅速定位到文件资源返回给上游。基于此我们设计了一套 URL 方式能够承载动态信息： http://img.example.com/${appName}/${image}/${variable}/${token}/${meta}/q.jpg appName: 业务名 variable: 图片信息 + 文案信息 + 模版信息 token: 加密参数, 把 variable 加密下校验 URL 合法性 meta: 裁剪信息 + 缩放信息 + 质量信息 技术架构 架构设计一切从性能出发，使用了 Nginx + lua + c 扩展的方式来实现服务，而并不需要 nginx 接受请求转发给其它服务进程处理，减少 IO 开销与进程切换的开销。 ngx_lua 采用 “one-coroutine-per-request” 的处理模型，对于每个用户请求，ngx_lua会唤醒一个协程用于执行用户代码处理请求，当请求处理完成这个协程会被销毁。每个协程都有一个独立的全局环境（变量空间），继承于全局共享的、只读的"comman data"。所以，被用户代码注入全局空间的任何变量都不会影响其他请求的处理，并且这些变量在请求处理完成后会被释放，这样就保证所有的用户代码都运行在一个"sandbox"（沙箱），这个沙箱与请求具有相同的生命周期。 得益于Lua协程的支持，ngx_lua在处理10000个并发请求时只需要很少的内存。根据测试，ngx_lua处理每个请求只需要2KB的内存，如果使用LuaJIT则会更少。所以ngx_lua非常适合用于实现可扩展的、高并发的服务。 lua 逻辑 Nginx 接受到请求后通过 location 匹配到对应的 lua 脚本并执行，lua 里面的逻辑主要包含参数提取，主要通过正则的方式取出来文案+图片+模版+缩放等信息，然后获取模版+获取图片信息然后调用 c 扩展实现合图，最后返回合成后的图片信息。 ...

最近在 GitHub 上看到一个非常火的图转代码开源项目（https://github.com/abi/screenshot-to-code) ，star 数量达到了 5万+，结合我自己在做的 UI2Code 项目，探究下它的具体实现方法。 为什么值得学习？ 过往在 UI2Code 项目中都是基于设计稿件，通过解析出结构化的 Json 数据，然后来做布局处理，最后转化成代码。这里有一个前提，即需要提供 UI 设计稿，设计稿通常被定义为 figma 稿件 或者 sketch 稿件等。而这个开源项目使用的是静态图片，是无图层信息的位图，那这也是最吸引我的地方。 screentshot-to-code 上传截图自动生成网页 HTML，背后原理是使用 Claude Sonnet 3.5 或 GPT-4o 生成代码，使用 DALL-E 3 生成相似图像。 经过一番摸索测试，发现这个项目生成的效果不太稳定，如果用在业务中看起来不太可行。那么有没有一种更稳定的实现方式呢？ 实现路径 先构思下整体流程： 大体而言，跟 UI2Code 流程无太大差异，最大区别还是在第一个步骤：如何将图片转成设计稿件。设计稿件转代码已经是一套现有非常成熟的解决方案。 下面看下如何解决图片转设计稿件。 图转稿件 首先，需要明确下稿件有哪几种数据类型，下面以我们自研的类 figma 工具而言，一个稿件的图层类型如下： 而我们从静态图片中能够提取出来的数据类型有三种： 文本类型 文本可以通过 ocr 的方式获取图像上包含的文字信息和文字坐标以及文字的颜色等信息。 图像类型 需要去分解一张大图上的各个小图，从而实现图片类型图层的提取。 容器类型 容器是一个组，它是若干文本和图像的区块，可以理解把一张图片划分成多个组，前端同学可以理解为我们经常用 div 来包裹若干内容图层。 文本 OCR OCR 是比较成熟的技术，为了快速验证，选取 https://github.com/PaddlePaddle/PaddleOCR?tab=readme-ov-file 作为方案实现。提取文字内容和文字坐标。 如何提取文字颜色？ 通过 OCR 获取文字坐标后，尝试通过 cv 的方式获取文字颜色。 def get_font_color(self, image, text_nodes): for node in text_nodes: x0 = node['x'] x1 = node['x'] + node['width'] y0 = node['y'] y1 = node['y'] + node['height'] _img = image[y0:y1, x0:x1] _gray = cv2.cvtColor(_img, cv2.COLOR_BGR2GRAY) threshold = np.mean(_gray) rec, mask_ = cv2.threshold(_gray, threshold, 255, cv2.THRESH_BINARY) p = len(np.where(mask_ == 255)[0]) / (mask_.shape[0] * mask_.shape[1]) if p < 0.5: font_value = 255 back_value = 0 else: font_value = 0 back_value = 255 font_color = np.mean(_img[np.where(mask_ == font_value)], axis=0) back_color = np.mean(_img[np.where(mask_ == back_value)], axis=0) node['font_color'] = (int(font_color[0]), int(font_color[1]), int(font_color[2])) node['bg_color'] = (int(back_color[0]), int(back_color[1]), int(back_color[2])) print(node) 图像分割 分割则需要用到当下比较流行的 SAM 模型， https://docs.ultralytics.com/zh/models/fast-sam/ ...

lodash 作为前端的基础工具库，已经被大量广泛使用，lodash 提供了非常多的工具函数，涵盖数组、字符串、对象等多种数据结构类型，而且 lodash 有个最大的优点是兼容性好，能处理各种边界情况，不担心各种 undefined null 或者类型不对导致的报错，所以广受欢迎。而最近出来了一个 es-toolkit，是一个基于 es6 新特性的工具函数库，它使用了大量新的 es 新特性，相比 lodash 速度提高 2-3 倍，体积缩小 97%。 以下是 es-toolkit 和 lodash 之间的主要比较 es-toolkit 提供了与 lodash 类似的关键工具函数，涵盖函数、数组、对象、字符串、数学和 Promise 等领域。 es-toolkit 的函数通常比 lodash 的函数更快，因为它们在实现中使用了现代 JavaScript API，并且使用 TypeScript 进行类型检查，减少了对额外防御性代码的需求。 性能基准测试表明，es-toolkit 函数的性能优于 lodash 的等效函数，有时优势明显。 es-toolkit 的函数与 lodash 的等效函数相比，包大小显著更小，从而导致更快的加载时间和更好的性能。 es-toolkit 通过利用现代 JavaScript 特性并避免 lodash 中存在的相互依赖关系来解决性能和包大小挑战。 es-toolkit 的函数大多是独立的，防止意外包含不必要的代码，而在 lodash 中工具函数通常是相互依赖的。 es-toolkit 的主要特性 函数，包括用于缓存函数结果的memoize和用于限制函数调用频率的debounce。 数组相关函数，如用于过滤重复项的uniq和用于找出数组之间差异的difference。 用于处理 JavaScript 对象的工具，如用于深度克隆的cloneDeep和用于将嵌套对象转换为扁平结构的flattenObject。 字符串操作工具，包括用于将字符串转换为短横线命名法（kebab-case）的kebabCase。 数学助手，如用于生成随机数的random和用于四舍五入的round。 类型保护函数，如用于轻松检查null或undefined值的isNil。 用于处理异步代码的工具，如用于暂停执行一段时间的delay。 性能 es-toolkit 的函数通常比 lodash 的函数更快，因为它们在实现中使用了现代 JavaScript API。例如，es-toolkit 的omit函数比 lodash 的 omit 函数快约 11.8 倍。 ...

想象一下你正在构建一个高性能的 Web 应用程序，比如一个 3D 游戏、一个图像编辑器或者一个数据处理仪表盘。你需要应用程序快速流畅，在不减速的情况下执行各种复杂操作。但是仅靠 JavaScript 能做到的有限：无论你如何优化，总会有 JavaScript 无法快速运行的代码。 WebAssembly（Wasm）—— 有了这项酷炫的技术，现在我们可以在浏览器中运行高性能代码，几乎就像在原生应用程序中一样。 WebAssembly 究竟是什么 WebAssembly 或 Wasm 到底是什么呢？它基本上是 JavaScript 的超级伙伴。WebAssembly 是一种低级二进制格式，可以在浏览器中以接近原生的速度运行。它是为计算密集型任务而构建的，而这些任务 JavaScript 自己处理起来效果不太好。 最棒的是，WebAssembly 与特定编程语言无关。它是一个与语言无关的平台，像 C、C++ 或 Rust 等语言的代码可以直接在浏览器中运行。开发者终于可以将其他语言的高性能代码编译成 WebAssembly，在 Web 上与 JavaScript 一起使用。 WebAssembly 特性 极速性能 Wasm 代码的运行速度几乎与原生应用程序一样快，所以你可以将它用于性能密集型任务。如果你正在构建一个图像编辑器，Wasm 可以轻松处理实时图像处理，如调整大小、颜色调整或应用滤镜，而让 JavaScript 处理用户界面。 跨浏览器一致 所有主流浏览器都支持 WebAssembly，即 Chrome、Firefox、Safari 和 Edge。这意味着无论你的用户在哪里，Wasm 代码的运行方式都相似。所以，我们可以保证应用程序的性能始终一致且快速。 更多语言选择 有了 WebAssembly，你不限于使用 JavaScript。你可以引入其他语言，如 C++ 或 Rust，它们以性能和内存效率著称。这对于速度至关重要的项目，或者当你想重用现有代码库时非常有用。 优化资源使用 WebAssembly 被开发为低内存占用。这使得它适合资源有限的设备，如移动设备。这一点非常重要，因为现代应用程序需要在各种设备上运行。 何时应该使用 WebAssembly 并非每个 Web 项目都需要 WebAssembly。对于许多事情，JavaScript 仍然完全够用：表单验证、基本交互、DOM 操作…… 但如果你需要更快的速度，或者你正在处理特别大量的数据，以下是 Wasm 可能派上用场的时候： 图形密集型应用程序：需要 3D 渲染的应用程序，如基于 Web 的游戏或模拟等 实时数据处理：需要快速计算的应用程序，如金融 / 科学分析工具等 Web 上的遗留代码：如果你有现有的用 C++ 或 Rust 编写的代码，WebAssembly 允许你将其带到 Web 上而无需完全重写。 举个栗子 我所在的团队就开发了一款类似于 figma 的图形编辑软件，其底层的渲染引擎则是由 c++ 实现，然后通过编译成 WebAssembly 后提供给 js 层调用，从而保障丝滑的操作体验。 ...

背景 最近在负责 D2C 生成组件代码的需求，首先我们在设计工具上实现了一个组件绑定功能。大概就是研发需要选择设计组件然后逐个绑定设计属性，生成代码就能包含组件代码，提高代码可用率。 由于手动绑定研发组件需要一个个点击表单，效率较低。大家的时间都很宝贵，因此批量操作通过自动化的方式就尤其有必要，插件是解决方案之一。 插件介绍 Figma 插件是扩展 Figma 设计工具功能的小程序。这些插件可以自动化设计流程，提供额外的设计资源，或者增强协作功能。设计师和开发者可以使用插件来提高工作效率，减少重复性工作。插件市场包含各种类型的插件，例如图标生成器、颜色工具、原型插件等。用户可以在 Figma 的插件商店中找到并安装这些插件，以满足特定的设计需求。 而 Relay 插件跟 Figma 插件一摸一样，所以开发 relay 插件直接先在 figma 环境开发即可。 搭建初始项目 具体可以参考这篇文章 https://www.figma.com/plugin-docs/plugin-quickstart-guide/ 初始化项目之后，我们就得到这样一个初始化工程： 插件运行环境 为了保持第三方代码的安全性，不会因为恶意代码影响 figma 平台运行，figma 提供了一套沙箱环境来执行 js 代码，并在沙箱环境中提供相应的 API 操作图层数据，从而达到插件与 figma 的交互。 在figma的沙箱环境是可以执行所有的 es6 语法，但不提供浏览器 DOM API。如果需要使用浏览器 API 或自定义 UI 则需要使用 figma.showUI() 方法实现，figma.showUI 的实质则是创建一个 iframe 来运行你的 UI 代码。 在沙箱与iframe之间则通过 postMessage 进行通信，这套架构在vscode的插件实现上也是类似方案。 逻辑与 UI 分离 首先，项目拆分成两个目录： native 用来存放逻辑相关的代码。执行在 sandbox 里的 js 代码，也是调用 figma API 的逻辑，如获取节点、创建节点、修改节点等； web 用来存放前端 UI 代码，用来渲染插件的界面。 ...

React Hooks 改变了我们在函数组件中管理状态和副作用的方式，为处理组件逻辑提供了更直观、灵活的途径。在众多可用的 Hooks 中，useEffect和useLayoutEffect在管理副作用（特别是涉及 DOM 更新或异步任务的副作用）方面起着关键作用。 选择正确的 Hook 对于保持最佳性能和流畅的用户体验至关重要。useEffect和useLayoutEffect都可用于类似任务，但基于执行时机和行为，它们各有特定优势。理解这些差异有助于避免不必要的重新渲染，并确保最佳的用户体验。 理解useEffect 用途 useEffect是 React 函数组件中处理副作用的首选 Hook，它取代了类组件中的生命周期方法，如componentDidMount、componentDidUpdate和componentWillUnmount，将它们整合为一个高效的 Hook。 工作原理 与类组件中同步运行的生命周期方法不同，useEffect在组件渲染之后执行。这种延迟执行允许浏览器在运行任何副作用之前更新屏幕，使useEffect不会阻塞渲染。因此，它非常适合那些不需要立即进行 DOM 更新的操作，如数据获取或事件监听器。 常见用例 useEffect用途广泛，常用于涉及非阻塞副作用的任务，以下是一些useEffect的理想场景： 1. 数据获取：使用useEffect从 API 获取数据并更新组件状态，且不影响初始渲染。 useEffect(() => { async function fetchData() { const response = await fetch('https://api.example.com/data'); const data = await response.json(); setData(data); } fetchData(); }, []); 2. 设置事件监听器：使用useEffect在组件挂载时设置事件监听器，并在卸载时清理 useEffect(() => { const handleResize = () => setWindowSize(window.innerWidth); window.addEventListener('resize', handleResize); return () => window.removeEventListener('resize', handleResize); }, []); 3. 管理异步任务：使用useEffect处理定时器或与本地存储交互，确保这些任务在组件挂载后运行 useEffect(() => { const timer = setTimeout(() => { setIsVisible(true); }, 1000); return () => clearTimeout(timer); }, []); 由于useEffect的非阻塞特性，它通常是默认选择，是处理大多数副作用且不干扰初始渲染的高效方式。 ...