老司机 iOS 周报，只为你呈现有价值的信息。

你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 Issues 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 Issues 提出。

文章

🐕 精通 UITableViewDiffableDataSource ——从入门到重构的现代 iOS 列表开发指南

@阿权：本文围绕 iOS 现代列表 UITableViewDiffableDataSource 展开，核心是替代传统数据源代理模式，解决列表开发中的崩溃、状态不一致等痛点，并在最后提供一个轻量工具集 DiffableDataSourceKit 来简化系统 API 的调用。文章核心内容如下：

1. 使用 UITableViewDiffableDataSource API，通过声明式的“快照”来管理数据状态，系统自动计算并执行 UI 更新动画，从而一劳永逸地解决了传统模式中数据与 U 状态不同步导致的崩溃问题。
2. 全文通过构建一个音乐播放列表 App 来贯穿始终，从移除 Storyboard、定义遵循 Hashable 协议的数据模型开始，一步步教你初始化数据源和填充数据。
3. 文章还详细讲解了：
   • 自定义多样化的单元格：包括使用传统的 Auto Layout 布局，以及利用 iOS 14+ 的 UIContentConfiguration 进行现代化配置。
   • 实现核心交互：具体涉及了拖拽重排、滑动删除，以及如何通过 Cell 的代理事件处理等交互。
   • 处理复杂逻辑：特别讲解了如何利用模型的 Hashable 来实现“原地刷新”而非替换的刷新机制。

除了文章提到的 UITableViewDiffableDataSource，用好这些技术，不妨可以再看看以下几个 WWDC：

1. WWDC19 - 215 - Advances in Collection View Layout
2. WWDC19 - 220 - Advances in UI Data Sources
3. WWDC20 - 10026 - Lists in UICollectionView
4. WWDC20 - 10027 - Modern cell configuration

另外，与其用 UITableView 承载数据，其实 Apple 更推荐使用 UICollectionView 来实现列表，甚至还提供了增强版的 Cell。

恰逢 App Store 要求用 Xcode 26 带来的强制升级，不少 App 也终于抛弃了 iOS 12、iOS 13，也是用新技术（也不新了）升级项目架构的最好时机。

除了 API 本身，我们也应关注到一些架构或设计模式上的变化与趋势：

1. 声明式。新的 API 更多使用构造时定义逻辑的声明式语法，在一开始就把相关的布局、样式等逻辑给定义好，后续不再通过各种存储属性配置逻辑。极大地减少了开发者对状态的维护。例如 UICollectionViewCompositionalLayout 通过 Item、可嵌套的 Group、Section 一层一层地在初始化配置布局。
2. 数据驱动。声明式常常是为了数据驱动，因为声明式定义的不是最终对象，而是一些前置的配置数据结构。例如 Cell 提供了 Configuration 结构体，通过配置和重新赋值结构体来实现 UI 更新，而不是直接操作 View。类似的，UIButton 也提供了类型的 Configuration 结构体用于配置 UI。更深一层的意义，驱动 UI 的配置数据、视图甚至可以复用的和无痛迁移的。例如 UITableViewCell 和 UICollectionViewCell 的配置类及其关联子视图是通用的，自定义 Cell 可以把重心放在自定义 Configuration 配置上，这样就可以把相同的视图样式套用在各种容器中。
3. 数据绑定。将索引替换为 id 甚至是具体业务类型。以往 UITableView、UICollectionView 的 API 都是围绕索引（IndexPath）展开的，所有的数据（DataSource）、布局（CollectionViewLayout）和视图（Presentation: Cell、ReuseableView）即使有分离，但都需要通过索引来交换。虽然这样简化了不同模块的耦合和通信逻辑，但因为大多数业务场景数据是动态的，这让索引只是个临时态，一不小心就会用错，轻则展示错误，重则引入崩溃。DiffableDataSource 最具里程碑的一点是剔除了索引，直接让具体业务模型跟 Cell 直接绑定，不经过索引。
4. 类型安全。不再是 Any/AnyObject，而是直接绑定一个具体的类型。常见做法是通过泛型机制将类型传入。
5. 用轮子，而不是造轮子。系统 API 足够自由，直接使用实例，而不是子类化自定义逻辑。以往的开发经验，都是一言不合就重写实现，重新造控件、布局，UIButton 和 UICollectionViewLayout 就是两个典型的 case。近年来系统 API 都在丰富使用的自由度和易用程度，例如 UIButton 提供了许多拿来就能用的灵活样式，开发者只需要微调个 Configuration 就是能实现业务效果。UICollectionViewCompositionalLayout 则是用 Item、Group、Section 构造足够复杂的布局场景。另外一点验证了这个趋势的是，iOS 26 中，只有官方提供的控件、导航框架才有完整的液态玻璃交互。

架构的演进一般是为了提高研效、减少出错。一个合理、高效的代码架构，在当业务需求变得复杂的时候，业务调用代码不会随业务的复杂而线性增长，而是逐渐减少。

🐎 Dart 官方再解释为什么放弃了宏编程，并转向优化 build_runner ? 和 Kotlin 的区别又是什么？

@Crazy：本文主要介绍了 Dart 官方放弃宏编程改为优化 build_runner 的原因，在读本文之前，要先明白什么是宏编程。文章中介绍了 Dart 在实现宏编程的过程中试用的方案与思考，放弃的原因总结起来有三个 :

1. 编译会卡在一个“先有鸡还是先有蛋”的死结
2. 工具链双前端导致宏支持会引发“工作量爆炸 + 性能灾难”
3. 即使做成了，也“高不成低不就”：替代不了 build_runner，不如直接扩展 build_runner 能力

文章最后还对比了 Kotlin 的 Compiler Plugins、KSP 与 Swift 的 Swift Macros 的差距，总的来说 build_runner 还有很长的一段路要走。

🐕 @_exported import VS public import

@AidenRao：Swift 6 带来了全新的 import 访问级别控制：@_exported import。它和我们熟悉的 public import 有什么不同？简单来说，public import 只是将一个模块声明为公开 API 的一部分，但使用者仍需手动导入它；而 @_exported import 则是将依赖的符号完全“吸收”，调用方无需关心底层依赖。文章深入对比了两者的意图和应用场景，并给出了明确建议：日常开发中应优先选择官方支持的 public import，仅在封装 SDK 或构建聚合模块（Umbrella Module）这类希望为用户简化导入操作的场景下，才考虑使用 @_exported。

🐕 MVVM + Reducer Pattern

@含笑饮砒霜：这篇文章主要讲述如何将 MVVM 架构与 Reducer 模式结合来提升 iOS 应用中状态管理的可控性和可维护性。作者指出：传统的 MVVM 模式在复杂状态下易出现分散的状态变更和难以追踪的问题，这会导致难调试、隐式状态转换、竞态条件等不良后果；而 Reducer 模式（受 Redux/TCA 启发）通过 “单一状态源 + 明确 action + 纯函数 reduce ” 的方式，使状态变更更可预测、更易测试。文章建议在 ViewModel 内部局部引入 reducer，把所有状态通过单一 reduce(state, action) 处理，并把副作用（如异步任务）当作 effects 处理，从而达到更明确、可追踪且易单元测试的效果，同时保留 MVVM 和领域层的清晰分层，不强依赖某个框架。

🐢 用第一性原理拆解 Agentic Coding：从理论到实操

@Cooper Chen：文章从第一性原理出发，系统拆解了 Agentic Coding 背后的底层逻辑与工程现实，澄清了一个常见误区：效率瓶颈不在于上下文窗口不够大，而在于我们如何与 AI 协作。作者以 LLM 的自回归生成与 Attention 机制为起点，深入分析了 Coding Agent 在长任务中常见的“走偏”“失忆”“局部最优”等问题，并指出这些并非工具缺陷，而是模型工作方式的必然结果。

文章最有价值之处，在于将理论约束转化为可执行的工程实践：通过“短对话、单任务”的工作方式控制上下文质量；用结构化配置文件和工具设计引导 Agent 行为；通过 Prompt Caching、Agent Loop、上下文压缩等机制提升系统稳定性。更进一步，作者提出“复利工程（Compounding Engineering）”这一关键理念——不把 AI 当一次性工具，而是通过文档、规范、测试和审查，将每一次经验沉淀为系统的长期记忆。

最终，文章给出的启示非常清晰：AI 编程不是魔法，而是一门需要刻意练习的协作技能。当你真正理解模型的边界，并用工程化方法加以约束和放大，AI 才能从“能写代码”进化为“可靠的编程合作者”。

🐎 Universal Links At Scale: The Challenges Nobody Talks About

@Damien：文章揭示了 Universal Links 在大规模应用中的隐藏复杂性：AASA 文件缺乏 JSON 模式验证导致静默失效，Apple CDN 缓存延迟使问题修复滞后，苹果特有通配符语法和 substitutionVariables 变量无现成工具支持。作者提出通过 CI 集成模式验证、CDN 同步检查、自定义正则解析和 staging 环境测试的完整方案，并开源了 Swift CLI 工具实现全链路自动化验证。

🐕 How I use Codex GPT 5.2 with Xcode (My Complete Workflow)

@JonyFang: 本视频深入介绍了如何让 AI 代理（如 Codex GPT 5.2）真正提升 iOS/macOS 开发效率的三个核心策略：

1. 构建脚本自动化（Build Scripts）：通过标准化的构建流程，让 AI 能够理解和复现你的构建环境
2. 让构建失败显而易见（Make Build Failures Obvious）：优化错误信息的呈现方式，使 AI 能够快速定位问题根源
3. 给你的代理装上"眼睛"（Give Your Agent Eyes）：这是最核心的部分 - 让 AI 能够"看到"应用运行时的状态，而不仅仅是读取代码

最有价值之处：作者强调了一个常被忽视的问题 - AI 代码助手不仅需要理解代码逻辑，更需要理解应用的运行时状态。通过工具如 Peekaboo 等，让 AI 能够获取视觉反馈（截图、UI 层级等），从而提供更精准的问题诊断和代码建议。这种"可观测性优先"的思路，与传统的代码审查工作流形成了有趣的对比，值得所有尝试将 AI 工具深度集成到开发流程中的团队参考。

视频时长约 49 分钟，适合希望系统性提升 AI 辅助开发效率的 iOS/macOS 开发者观看。

工具

🐎 Skip Is Now Free and Open Source

@Crazy：Skip 框架正式免费并且开源，该库从 2023 年开始开发，已有三年的开发历程。该库的目的是让开发者能够仅用一套 Swift 与 SwiftUI 代码库，同时打造 iOS 与 Android 上的高品质移动应用——而且不必接受那些自“跨平台工具诞生以来就一直存在”的妥协。因为 Skip 是采用编译为 Kotlin 与 Compose 的方式，所以相应的执行效率是非常高的。相较于其他的跨平台开发，效率高，并且使用的是 Swift 语言。既然已经免费并开源，移动端开发的时候又多了一个可供选择的跨端技术。

内推

重新开始更新「iOS 靠谱内推专题」，整理了最近明确在招人的岗位，供大家参考

具体信息请移步：https://www.yuque.com/iosalliance/article/bhutav 进行查看（如有招聘需求请联系 iTDriverr）

关注我们

我们是「老司机技术周报」，一个持续追求精品 iOS 内容的技术公众号，欢迎关注。

关注有礼，关注【老司机技术周报】，回复「2024」，领取 2024 及往年内参

同时也支持了 RSS 订阅：https://github.com/SwiftOldDriver/iOS-Weekly/releases.atom 。

说明

🚧 表示需某工具，🌟 表示编辑推荐

预计阅读时间：🐎 很快就能读完（1 - 10 mins）；🐕 中等 （10 - 20 mins）；🐢 慢（20+ mins）

JavaScript对象的精髓与哲学思考——解析《JavaScript语言精粹》第三章 引言：为什么对象是JavaScript的灵魂？ 在编程语言的世界中，JavaScript的对象系统独树一帜。

【Unity Shader Graph 使用与特效实现】专栏-直达

在Unity的Shader Graph中，NormalVector节点是一个基础且重要的工具，它允许着色器访问网格的法线矢量信息。法线矢量在计算机图形学中扮演着关键角色，它定义了表面的朝向，是光照计算、材质表现和各种视觉效果的基础。

节点概述

NormalVector节点为着色器编写者提供了获取网格法线数据的便捷途径。无论是顶点法线还是片元法线，这个节点都能让开发者轻松地在不同的坐标空间中操作这些数据。通过简单的参数设置，就可以将法线矢量转换到所需的坐标空间，大大简化了复杂着色器的开发过程。

法线矢量的本质是垂直于表面的单位向量，在三维空间中表示为(x, y, z)坐标。在Shader Graph中，这些数据通常来自3D模型的顶点数据，或者通过法线贴图等技术进行修改和增强。

参数详解

Space参数

Space参数决定了法线矢量输出的坐标空间，这是NormalVector节点最核心的功能。不同的坐标空间适用于不同的着色场景和计算需求。

• Object空间：也称为模型空间，这是法线数据最原始的存储空间。在Object空间中，法线相对于模型本身的坐标系定义，不考虑模型的旋转、缩放或平移变换。当模型发生变换时，Object空间中的法线不会自动更新，需要手动进行相应的变换计算。
• View空间：也称为相机空间或眼睛空间，在这个空间中，所有坐标都是相对于相机的位置和方向定义的。View空间的原点通常是相机的位置，Z轴指向相机的观察方向。这个空间特别适合与视角相关的效果，如边缘光、反射和折射。
• World空间：World空间中的坐标是相对于场景的世界坐标系定义的。无论模型如何移动或旋转，World空间提供了统一的参考框架。这个空间常用于光照计算、阴影生成和全局效果。
• Tangent空间：这是一个特殊的局部空间，主要用于法线贴图。在Tangent空间中，法线是相对于表面本身定义的，Z轴与表面法线对齐，X轴与切向量对齐，Y轴与副法线对齐。这种表示方法使得法线贴图可以在不同朝向的表面上重复使用。

选择正确的坐标空间对着色器的正确性和性能至关重要。错误的空间选择可能导致光照计算错误、视觉效果异常或性能下降。

端口信息

NormalVector节点只有一个输出端口：

• Out：输出类型为Vector 3，表示三维矢量。这个端口输出的是根据Space参数选择在对应坐标空间中的法线矢量。输出值通常是归一化的单位矢量，但在某些情况下（如使用非统一缩放时）可能需要重新归一化。

使用场景与示例

基础光照计算

法线矢量的一个主要应用是光照计算。在Lambert光照模型中，表面亮度取决于光线方向与表面法线之间的夹角。

HLSL

// 简化的Lambert光照计算
float3 lightDir = normalize(_WorldSpaceLightPos0.xyz);
float3 worldNormal = NormalVector节点输出（World空间）;
float NdotL = max(0, dot(worldNormal, lightDir));
float3 diffuse = _LightColor0 * NdotL;

在这个示例中，我们首先获取世界空间中的法线矢量和光线方向，然后计算它们的点积。点积结果决定了表面接收到的光照强度，这是大多数基础光照模型的核心计算。

法线贴图应用

法线贴图是现代实时渲染中增强表面细节的关键技术。NormalVector节点在应用法线贴图时起着桥梁作用。

HLSL

// 法线贴图应用流程
float3 tangentNormal = tex2D(_NormalMap, uv).xyz * 2 - 1; // 从[0,1]转换到[-1,1]
float3 worldNormal = NormalVector节点输出（World空间）;
// 使用TBN矩阵将切线空间法线转换到世界空间
float3x3 TBN = float3x3(
    IN.tangent.xyz,
    cross(IN.normal, IN.tangent.xyz) * IN.tangent.w,
    IN.normal
);
float3 mappedNormal = mul(TBN, tangentNormal);

这个示例展示了如何将切线空间中的法线贴图数据转换到世界空间。首先从法线贴图中采样并调整数值范围，然后使用TBN（切线-副切线-法线）矩阵进行空间转换。

边缘检测与轮廓光

利用View空间中的法线可以创建各种与视角相关的效果，如边缘光和轮廓检测。

HLSL

// 边缘光效果
float3 viewNormal = normalize(mul((float3x3)UNITY_MATRIX_V, NormalVector节点输出（World空间）));
float3 viewDir = normalize(UnityWorldToViewPos(IN.worldPos));
float rim = 1 - abs(dot(viewNormal, viewDir));
float rimLight = pow(rim, _RimPower) * _RimIntensity;

在这个示例中，我们首先将世界空间法线转换到View空间，然后计算法线与视角方向的点积。当表面几乎垂直于视角方向时（即边缘处），点积接近0，从而产生边缘光效果。

环境遮挡与全局光照

法线信息对于环境遮挡和全局光照计算也至关重要。

HLSL

// 简化的环境遮挡
float3 worldNormal = NormalVector节点输出（World空间）;
float ambientOcclusion = 1.0;

// 基于法线方向的简单环境光遮蔽
// 这里可以使用更复杂的算法，如SSAO或烘焙的AO贴图
ambientOcclusion *= (worldNormal.y * 0.5 + 0.5); // 模拟顶部光照更多

// 应用环境光
float3 ambient = UNITY_LIGHTMODEL_AMBIENT * ambientOcclusion;

这个简单的示例展示了如何用法线方向来模拟环境光遮蔽效果。在实际项目中，通常会结合更复杂的算法或预计算的数据。

高级应用技巧

法线重定向与混合

在某些情况下，需要将法线从一个表面重定向到另一个表面，或者在不同法线源之间进行混合。

HLSL

// 法线混合示例
float3 normalA = tex2D(_NormalMapA, uv).xyz;
float3 normalB = tex2D(_NormalMapB, uv).xyz;
float blendFactor = _BlendFactor;

// 使用线性插值混合法线
float3 blendedNormal = lerp(normalA, normalB, blendFactor);

// 或者使用更精确的球面线性插值
// float3 blendedNormal = normalize(lerp(normalA, normalB, blendFactor));

法线混合是一个复杂的话题，因为简单的线性插值可能不会保持法线的单位长度。在实际应用中，可能需要重新归一化或使用更高级的插值方法。

法线空间转换优化

在性能关键的场景中，法线空间转换可能需要优化。

HLSL

// 优化的世界空间法线计算
// 传统方法
float3 worldNormal = normalize(mul(IN.normal, (float3x3)unity_WorldToObject));

// 优化方法 - 使用逆转置矩阵（处理非统一缩放）
float3 worldNormal = normalize(mul(transpose((float3x3)unity_WorldToObject), IN.normal));

当模型应用了非统一缩放时，直接使用模型矩阵变换法线会导致错误的结果。在这种情况下，需要使用模型矩阵的逆转置矩阵来正确变换法线。

法线可视化与调试

在开发过程中，可视化法线矢量对于调试着色器非常有用。

HLSL

// 法线可视化
float3 worldNormal = NormalVector节点输出（World空间）;
// 将法线从[-1,1]范围映射到[0,1]范围以便可视化
float3 normalColor = worldNormal * 0.5 + 0.5;
return float4(normalColor, 1.0);

这个简单的着色器将法线矢量的各个分量映射到颜色通道，从而可以直观地查看法线的方向和分布。

常见问题与解决方案

法线不连续问题

当使用低多边形模型或不当的UV展开时，可能会遇到法线不连续的问题。

• 问题表现：表面出现不自然的硬边或接缝
• 解决方案：
  • 确保模型有适当的平滑组设置
  • 检查UV展开是否导致法线贴图采样错误
  • 考虑使用更高精度的模型或细分表面

性能考量

法线计算可能会成为性能瓶颈，特别是在移动设备或复杂场景中。

• 优化策略：
  • 在顶点着色器中计算法线，而不是片元着色器
  • 使用更简单的法线计算，如省略归一化步骤（如果对视觉效果影响不大）
  • 考虑使用法线贴图的压缩格式以减少内存带宽

法线精度问题

在特定情况下，法线计算可能会遇到精度问题，导致视觉瑕疵。

• 问题表现：闪烁的表面、带状伪影或不准确的光照
• 解决方案：
  • 使用更高精度的数据类型（如half改为float）
  • 确保法线贴图使用适当的格式和压缩
  • 检查法线变换矩阵的精度和正确性

与其他节点的配合使用

NormalVector节点很少单独使用，通常与其他Shader Graph节点结合以实现复杂的效果。

• 与Dot Product节点结合：用于计算光照强度、菲涅尔效应等
• 与Transform节点结合：在不同坐标空间之间转换法线
• 与Normalize节点结合：确保法线保持单位长度
• 与Sample Texture 2D节点结合：应用法线贴图
• 与Fresnel Effect节点结合：创建基于视角的效果

最佳实践

为了确保NormalVector节点的正确使用和最佳性能，建议遵循以下最佳实践：

• 始终考虑法线是否需要归一化，特别是在进行数学运算或空间变换后
• 选择最适合当前计算任务的坐标空间，避免不必要的空间转换
• 在性能敏感的场景中，尽可能在顶点着色器中计算法线相关数据
• 使用适当的数据类型平衡精度和性能
• 定期验证法线计算的正确性，特别是在使用复杂变换或混合时

---

【Unity Shader Graph 使用与特效实现】专栏-直达 （欢迎点赞留言探讨，更多人加入进来能更加完善这个探索的过程，🙏）

在 JavaScript 的世界里，函数不仅是代码的执行单元，更是构建复杂应用的核心积木。正如你的笔记所言：“函数包含一组语句，它们是 JavaScript 的基础模块单元，用于代码复用、信息隐藏和组合调用。” 本文将系统梳理 JavaScript 函数的核心特性——从其对象本质、四种调用模式，到闭包、模块化等高级概念，助你真正掌握这门语言的灵魂。

---

一、函数即对象：一切皆可赋值

JavaScript 中最颠覆传统编程认知的一点是：函数是头等对象（First-class Object）

function add(a, b) {
    return a + b;
  }
  
  // 函数可以像普通变量一样被赋值、传递、存储
  var myFunc = add;
  console.log(myFunc(2, 3)); // 5
  
  // 甚至可以作为对象属性（方法）
  var calculator = { operate: add };

✅ 函数对象的特殊性：

• 它拥有普通对象的所有能力（可添加属性、可作为参数传递）；
• 唯一区别：它可以通过 () 被调用（invoked） ；
• 其原型链为：add → Function.prototype → Object.prototype。

💡 正因函数是对象，我们才能实现回调、高阶函数、闭包等强大模式。

---

二、函数字面量：声明的四种方式

最常用的是函数字面量（Function Literal） ：

// 命名函数（推荐，便于调试）
function greet(name) {
    return "Hello, " + name;
  }
  
  // 匿名函数（常用于回调）
  setTimeout(function() {
    console.log("Delayed!");
  }, 1000);

此外还有：

• 函数表达式：const fn = function() {}
• 箭头函数（ES6+） ：const fn = () => {}

📌 命名建议：除非作为简短回调，否则优先使用命名函数，提升堆栈可读性。

---

三、四大调用模式：this 的命运由谁决定？

函数调用时，会自动获得两个“免费”参数：this 和 arguments。而 this 的指向，取决于调用方式。

1. 方法调用模式（Method Invocation）

var obj = {
    name: "Alice",
    sayHi: function() {
      console.log(this.name); // "Alice" —— this 指向 obj
    }
  };
  obj.sayHi();

✅ this 绑定到调用对象，这是面向对象编程的基础。

2. 函数调用模式（Function Invocation）

function sayName() {
    console.log(this); // 非严格模式：window；严格模式：undefined
  }
  sayName(); // 直接调用

⚠️ 危险！  在非严格模式下，this 意外指向全局对象，易引发 bug。

3. 构造器调用模式（Constructor Invocation）

function Person(name) {
    this.name = name; // this 指向新创建的实例
  }
  var p = new Person("Bob");

✅ 使用 new 时：

• 创建新对象；
• this 绑定到该对象；
• 若无显式 return 对象，则返回 this。

4. Apply/Call 调用模式（Explicit Invocation）

function introduce() {
    console.log("I'm " + this.name);
  }
  
  var user = { name: "Carol" };
  introduce.call(user);   // "I'm Carol"
  introduce.apply(user);  // 同上（参数以数组形式传入）

✅ 显式指定 this，是实现函数借用、绑定上下文的关键。

🌟 现代替代：ES5+ 的 bind() 可创建永久绑定 this 的新函数。

---

四、参数与返回：灵活但需谨慎

参数：arguments 对象

function sum() {
    let total = 0;
    for (let i = 0; i < arguments.length; i++) {
      total += arguments[i];
    }
    return total;
  }
  sum(1, 2, 3); // 6

• arguments 是类数组对象，无 map/forEach 等方法；
• 现代替代：使用 Rest 参数（...args）  获取真数组：

function sum(...numbers) {
    return numbers.reduce((a, b) => a + b, 0);
  }

返回值规则

• 无 return → 返回 undefined；
• 构造函数中若 return 非对象 → 忽略，仍返回 this；
• 若 return 对象 → 返回该对象（覆盖 this）。

---

五、闭包：函数的“记忆”能力

闭包 = 内部函数 + 外部作用域的引用

function counter() {
    var count = 0;
    return function() {
      count++;
      return count;
    };
  }
  
  var c = counter();
  console.log(c()); // 1
  console.log(c()); // 2 —— count 被“记住”了！

✅ 闭包的价值：

• 数据私有化：count 外部无法直接访问；
• 状态保持：函数“记住”了创建时的环境；
• 模块化基础：实现信息隐藏。

---

六、模块模式：告别全局污染

利用闭包，可构建模块（Module） ——提供接口但隐藏内部状态：

var MyModule = (function() {
    var privateVar = "secret";
  
    function privateMethod() {
      console.log(privateVar);
    }
  
    return {
      publicMethod: function() {
        privateMethod();
      }
    };
  })();
  
  MyModule.publicMethod(); // "secret"
  // MyModule.privateVar → undefined（无法访问）

✅ 优势：

• 避免全局变量冲突；
• 实现封装与解耦；
• 是现代 ES6 模块（import/export）的思想前身。

---

七、高级技巧：记忆化、套用与级联

1. 记忆化（Memoization）

缓存计算结果，避免重复运算：

function fibonacci(n, memo = {}) {
    if (n in memo) return memo[n];
    if (n <= 1) return n;
    memo[n] = fibonacci(n - 1, memo) + fibonacci(n - 2, memo);
    return memo[n];
  }

2. 套用（Currying）

将多参数函数转换为一系列单参数函数：

function add(a) {
    return function(b) {
      return a + b;
    };
  }
  var add5 = add(5);
  add5(3); // 8

3. 级联（Chaining）

方法返回对象自身，支持链式调用：

var obj = {
    value: 0,
    add: function(x) {
      this.value += x;
      return this; // 关键：返回 this
    },
    log: function() {
      console.log(this.value);
      return this;
    }
  };
  
  obj.add(2).add(3).log(); // 5

八、异常处理：优雅应对错误

try {
    throw new Error("Something went wrong!");
  } catch (e) {
    console.error(e.message);
  } finally {
    console.log("Cleanup");
  }

• throw 抛出异常对象（建议用 Error 实例）；
• catch 捕获并处理；
• finally 无论是否出错都会执行。

---

结语：函数是 JavaScript 的灵魂

从简单的代码复用，到复杂的闭包、模块、高阶函数，JavaScript 的函数机制赋予了开发者极大的表达力。理解其对象本质、this 绑定规则、作用域链与闭包原理，是写出健壮、可维护代码的前提。

正如 Douglas Crockford 所言： “JavaScript 的精华，就在于它的函数。”  掌握函数，你就掌握了这门语言的钥匙。

36氪获悉，东吴证券发布研究报告称，截至1月22日，公募基金四季报已披露完毕。从市场主线来看，进入1月下旬后，年报业绩预告将进入密集披露期，市场主线将聚焦业绩线。东吴证券挖掘背后资金逻辑，提炼出四条核心线索，为后续大势研判与板块配置提供指引。

Server Components vs Client Components：Next.js 开发者的选择指南

在 Next.js 的世界里，理解这两种组件的区别，就像掌握武术中的“刚柔并济”

大家好！今天我们来深入探讨 Next.js 13+ 中最重要的架构变革：Server Components（服务端组件） 与 Client Components（客户端组件）。这两者的选择不仅影响性能，更关乎应用架构的根本决策。

📊 快速对比：一图看懂核心差异

先来个直观对比，让大家有个整体概念：

特性维度	Server Components	Client Components
渲染位置	服务端	客户端
Bundle大小	零打包，不发送到客户端	需要打包并发送到客户端
数据获取	直接访问数据库/API	通过API端点获取
交互性	无（纯展示）	完全交互式
生命周期	无（每次请求重新渲染）	完整React生命周期
DOM API	不可用	完全可用
状态管理	无状态	useState、useReducer等
第三方库	需兼容服务端渲染	无限制

🔍 深入解析：它们到底做了什么？

Server Components：服务端的“魔法”

// app/products/page.js - 默认就是Server Component
import { db } from '@/lib/db'

// 服务端组件可以直接访问数据库！
export default async function ProductsPage() {
  // 直接读取数据库，不需要API路由
  const products = await db.products.findMany({
    where: { isPublished: true }
  })
  
  return (
    <div>
      <h1>产品列表</h1>
      {/* 数据直接嵌入HTML，对SEO友好 */}
      <ul>
        {products.map(product => (
          <li key={product.id}>
            <h2>{product.name}</h2>
            <p>{product.description}</p>
            {/* 注意：这里不能有事件处理器 */}
          </li>
        ))}
      </ul>
    </div>
  )
}

Server Components的优势：

• 零客户端Bundle：代码永远不会发送到浏览器
• 直接数据访问：减少客户端-服务器往返
• 自动代码分割：只发送当前路由需要的代码
• 敏感信息安全：API密钥、数据库凭证安全保留在服务端

Client Components：客户端的“灵魂”

'use client' // 这个指令至关重要！

import { useState, useEffect } from 'react'
import { addToCart } from '@/actions/cart'
import { LikeButton } from './LikeButton'

export default function ProductCard({ initialProduct }) {
  const [product, setProduct] = useState(initialProduct)
  const [isLiked, setIsLiked] = useState(false)
  
  // 客户端特有的生命周期
  useEffect(() => {
    // 可以访问浏览器API
    const viewed = localStorage.getItem(`viewed_${product.id}`)
    if (!viewed) {
      localStorage.setItem(`viewed_${product.id}`, 'true')
      // 发送浏览记录到分析服务
      analytics.track('product_view', { id: product.id })
    }
  }, [product.id])
  
  // 交互事件处理
  const handleAddToCart = async () => {
    await addToCart(product.id)
    // 显示动画反馈
    // 更新购物车图标数量
  }
  
  return (
    <div className="product-card">
      <h3>{product.name}</h3>
      <p>{product.price}元</p>
      
      {/* 交互式组件 */}
      <button 
        onClick={handleAddToCart}
        className="add-to-cart-btn"
      >
        加入购物车
      </button>
      
      {/* 使用第三方UI库 */}
      <LikeButton 
        isLiked={isLiked}
        onChange={setIsLiked}
      />
      
      {/* 使用状态驱动的UI */}
      <div className={`stock-status ${product.stock < 10 ? 'low' : ''}`}>
        库存: {product.stock}
      </div>
    </div>
  )
}

🎯 黄金选择法则：什么时候用什么？

默认选择 Server Component 当：

• ✅ 纯数据展示，无需交互
• ✅ 访问后端资源（数据库、文件系统）
• ✅ 需要减少客户端JavaScript体积
• ✅ 包含敏感逻辑或数据
• ✅ SEO是关键考虑因素
• ✅ 内容基本静态，变化不频繁

// ✅ 应该用 Server Component
// 博客文章页面
export default async function BlogPost({ slug }) {
  const post = await db.posts.findUnique({ where: { slug } })
  const relatedPosts = await db.posts.findMany({
    where: { category: post.category },
    take: 3
  })
  
  return <Article content={post.content} related={relatedPosts} />
}

必须使用 Client Component 当：

• ✅ 需要用户交互（点击、输入、拖拽）
• ✅ 使用浏览器API（localStorage、geolocation）
• ✅ 需要状态管理（useState、useReducer）
• ✅ 使用第三方交互式库（地图、图表、富文本编辑器）
• ✅ 需要生命周期效果（useEffect）
• ✅ 实现动画或过渡效果

'use client'
// ✅ 必须用 Client Component
// 实时搜索组件
export default function SearchBox() {
  const [query, setQuery] = useState('')
  const [results, setResults] = useState([])
  const [isSearching, setIsSearching] = useState(false)
  
  // 防抖搜索
  useEffect(() => {
    if (!query.trim()) return
    
    const timer = setTimeout(async () => {
      setIsSearching(true)
      const res = await fetch(`/api/search?q=${query}`)
      const data = await res.json()
      setResults(data)
      setIsSearching(false)
    }, 300)
    
    return () => clearTimeout(timer)
  }, [query])
  
  return (
    <div>
      <input 
        value={query}
        onChange={(e) => setQuery(e.target.value)}
        placeholder="搜索..."
      />
      {isSearching && <Spinner />}
      <SearchResults results={results} />
    </div>
  )
}

🛠️ 混合使用：现实世界的案例

真正的应用往往是混合使用的，下面看一个电商产品页面的例子：

// app/product/[id]/page.js - Server Component
import { db } from '@/lib/db'
import ProductDetails from './ProductDetails' // Client Component
import ProductReviews from './ProductReviews' // Server Component
import AddToCartButton from '@/components/AddToCartButton' // Client Component

export default async function ProductPage({ params }) {
  // 服务端：获取核心数据
  const product = await db.products.findUnique({
    where: { id: params.id },
    include: { category: true }
  })
  
  // 服务端：获取评论（SEO重要）
  const reviews = await db.reviews.findMany({
    where: { productId: params.id, isVerified: true },
    take: 10
  })
  
  // 服务端：获取推荐（个性化）
  const recommendations = await getRecommendations(product.id)
  
  return (
    <div className="product-page">
      {/* 服务器组件传递数据到客户端组件 */}
      <ProductDetails 
        product={product} 
        // 客户端交互：收藏、分享、放大图片
      />
      
      {/* 服务器组件：纯展示评论 */}
      <ProductReviews 
        reviews={reviews}
        // 客户端交互：点赞、回复评论（嵌套的客户端组件）
      />
      
      {/* 客户端组件：购物车交互 */}
      <AddToCartButton 
        productId={product.id}
        stock={product.stock}
      />
      
      {/* 服务端组件：推荐列表 */}
      <RecommendationList 
        products={recommendations}
        // 每个推荐项内部可能有客户端交互
      />
    </div>
  )
}

💡 高级模式与最佳实践

1. 组件边界优化

// 不好的做法：整个页面都是客户端组件
'use client' // ❌ 不要轻易在顶层加这个

// 好的做法：精确控制客户端边界
export default function UserDashboard() {
  return (
    <div>
      {/* 服务端组件：用户信息（静态） */}
      <UserProfile />
      
      {/* 服务端组件：统计数据 */}
      <AnalyticsSummary />
      
      {/* 精确的客户端边界：交互式图表 */}
      <div className="interactive-section">
        <RealTimeChart />
        <FilterControls />
      </div>
    </div>
  )
}

2. 数据传递模式

// ✅ 模式：服务端获取数据，传递给客户端
// Server Component
export default async function Dashboard() {
  const initialData = await fetchDashboardData()
  
  return <InteractiveDashboard initialData={initialData} />
}

// Client Component
'use client'
function InteractiveDashboard({ initialData }) {
  const [data, setData] = useState(initialData)
  
  // 客户端更新数据
  const refreshData = async () => {
    const newData = await fetch('/api/dashboard')
    setData(newData)
  }
  
  return (
    <>
      <DashboardUI data={data} />
      <button onClick={refreshData}>刷新</button>
    </>
  )
}

3. 性能优化策略

// 策略：代码分割 + 懒加载客户端组件
import dynamic from 'next/dynamic'

// 重交互组件动态导入
const HeavyChart = dynamic(
  () => import('@/components/HeavyChart'),
  { 
    ssr: false, // 不在服务端渲染
    loading: () => <ChartSkeleton /> 
  }
)

export default function AnalyticsPage() {
  return (
    <div>
      <h1>数据分析</h1>
      {/* 这个组件只在客户端加载 */}
      <HeavyChart />
    </div>
  )
}

🚨 常见陷阱与解决方案

陷阱1：在Server Component中使用客户端特性

// ❌ 错误：在服务端组件中使用useState
export default function ServerComponent() {
  const [count, setCount] = useState(0) // 编译错误！
  return <div>{count}</div>
}

// ✅ 解决方案：提取为客户端组件
'use client'
function Counter() {
  const [count, setCount] = useState(0)
  return <div>{count}</div>
}

export default function Page() {
  return <Counter />
}

陷阱2：不必要的客户端边界

// ❌ 不必要的客户端标记
'use client'
export default function Page() {
  // 这个组件没有任何交互，却标记为客户端！
  return <div>静态内容</div>
}

// ✅ 保持为服务端组件
export default function Page() {
  return <div>静态内容</div>
}

陷阱3：过度嵌套导致的序列化问题

// ❌ 传递无法序列化的数据
export default async function Page() {
  const data = await fetchData()
  // 函数、Date对象等无法序列化
  return <ClientComponent data={data} callback={() => {}} />
}

// ✅ 仅传递可序列化数据
export default async function Page() {
  const data = await fetchData()
  // 清理数据，确保可序列化
  const serializableData = JSON.parse(JSON.stringify(data))
  return <ClientComponent data={serializableData} />
}

📈 性能影响：真实数据对比

根据Vercel的测试数据：

场景	纯客户端渲染	混合渲染（推荐）	纯服务端组件
首屏加载时间	2.8s	1.2s ⭐	1.0s
可交互时间	2.8s	1.4s ⭐	N/A
Bundle大小	245KB	78KB ⭐	12KB
SEO友好度	中	高 ⭐	高

结论：混合方案在绝大多数场景下是最佳选择！

🔮 未来趋势

1. Partial Prerendering（部分预渲染）：Next.js 14+ 的新特性，自动混合静态和动态内容
2. Server Actions：更深度集成服务端逻辑
3. Edge Runtime优化：组件级别的边缘计算部署

🎓 总结：决策流程图

这里给你一个快速决策流程图：

开始
  ↓
组件需要交互吗？
  ↓
是 → 需要浏览器API吗？ → 是 → Client Component ✅
  ↓                ↓
否               否 → 有状态吗？ → 是 → Client Component ✅
  ↓                ↓           ↓
Server Component ← 否 ← 否 ← 仅展示数据？
  ↓
需要考虑Bundle大小吗？ → 是 → Server Component ✅
  ↓
否
↓
Client Component ✅

💬 互动讨论

话题讨论：

1. 你在项目中最大的 Server/Client Component 挑战是什么？
2. 有没有遇到性能大幅提升的成功案例？
3. 你如何向团队成员解释这两种组件的区别？

欢迎在评论区分享你的经验和见解！

36氪获悉，上海沪工公告，公司持股5%以上股东上海明鑫光储企业管理有限公司因自身资金需求，计划自公告披露之日起15个交易日后的3个月内，通过集中竞价和大宗交易方式合计减持公司股份不超过1010.72万股，即不超过公司总股本的3%。其中，通过集中竞价减持不超过336.91万股，通过大宗交易减持不超过673.81万股。本次减持不设价格区间。

React 状态管理的架构演进：为什么你不再需要把所有数据塞进全局 Store 引言：状态管理的困境 如果你写过中大型 React 应用，一定遇到过这样的场景： 然后在组件里，你需要这样使用： 看起来

背景 上篇文章我们聊了Hooks诞生初心是为了解决什么问题，今天我们继续探讨 Hooks的 具体执行方案 前置：先建立「函数组件 + Hook」的全局执行流程 Hook 的所有操作都嵌套在 React

在现代前端 monorepo 中，pnpm install 看似一句命令，背后却有一套精密的 全局视图 + 子包依赖管理 + 扁平化安装策略。

在字符串处理类算法题中，Z 字形变换是一道经典的「规律提炼 + 代码优化」双重点题型，频繁出现在面试与算法练习中。它的核心难点不在于实现功能，而在于如何精准捕捉 Z 字形排列的周期性规律，同时兼顾代码

📝 前言 还在为调个页面布局熬大夜？用 float 排个版，元素到处乱跑；用 position 定个位，稍微改点东西就全乱套。不想熬夜了😭！ 别慌，今天咱们就来聊聊前端界的 “救星” — Flex 弹

Catalog 协议不是安装机制，而是版本管理机制。 它在 monorepo 中提供了一个“单一版本源头”， 子包只负责声明依赖，版本号由根目录统一控制。 与 workspace 协议配合使用，可以实

workspace: 协议不是版本控制工具，而是依赖来源控制工具。 它的作用是明确告诉 pnpm：“这个依赖只能来自当前 workspace，而不是外部仓库。”

你想弄清楚 Fetch 流式的核心定义、工作原理和实际价值，简单来说，Fetch 流式是 Fetch API 提供的「边接收、边处理」数据的能力，它让前端不再需要等待服务端返回完整的响应数据，而是能逐

大模型流式响应（打字机效果）完整实例 你需要的是结合 Fetch、EventSource(SSE) 和 AbortController 实现大模型流式响应（打字机效果）的可运行实例，下面将分别提供两种

用逻辑概念替代 API 记忆
promise-logic 的设计是：开发者应专注于业务逻辑，而非 Promise API 的细节。
传统 Promise 组合（如 Promise.all、Promise.race）的命名与语义不够直观，尤其在复杂异步场景下，代码可读性迅速下降。
promise-logic 通过逻辑门（Logic Gate） 的方式，将异步组合抽象为 and、or、xor 等逻辑操作，使代码语义清晰、逻辑自解释。

---

相关功能

1. 逻辑语义化

   • and：所有任务必须成功（等价于 Promise.all）

   • or：至少一个任务成功（等价于 Promise.race）

   • xor：有且仅有一个任务成功

   • nand：所有任务均失败

   • not：反转单个 Promise 的结果

   • majority：多数任务成功

2. 零依赖
   仅依赖原生 Promise，无额外运行时依赖。

3. 全测试覆盖
   所有逻辑门均经过严格单元测试，确保行为符合预期。

4. 错误分类明确

   • PromiseLogicError 统一错误类型
   • error.type 区分具体逻辑错误（如 'XOR_ERROR'）

---

安装

npm install promise-logic

---

快速开始

示例：主备服务调用（XOR 场景）

import { PromiseLogic } from 'promise-logic';

// 主服务调用
const primary = fetch('https://api.main.com/data');
// 备用服务调用
const backup = fetch('https://api.backup.com/data');

// 执行 XOR 逻辑：有且仅有一个成功
PromiseLogic.xor([primary, backup])
  .then(result => {
    console.log('成功获取数据:', result);
  })
  .catch(error => {
    if (error.type === 'XOR_ERROR') {
      console.error('主备服务均成功或均失败，不符合 XOR 语义');
    } else {
      console.error('网络错误:', error);
    }
  });

示例：多数决决策（Majority 场景）

import { PromiseLogic } from 'promise-logic';

const services = [
  fetch('https://api.node1.com/vote'),
  fetch('https://api.node2.com/vote'),
  fetch('https://api.node3.com/vote')
];

PromiseLogic.majority(services)
  .then(results => {
    console.log('多数服务返回成功:', results);
  })
  .catch(error => {
    console.error('多数服务失败:', error);
  });

typescript类型断言场景

import { PromiseLogic } from 'promise-logic/typescript';

const services = [
  fetch('https://api.node1.com/vote'),
  fetch('https://api.node2.com/vote'),
  fetch('https://api.node3.com/vote')
];

//可以进行类型断言，也可以默认让PromiseLogic自动推断类型
PromiseLogic.majority<Response>(services)
  .then(results => {
    console.log('多数服务返回成功:', results);
  })
  .catch(error => {
    console.error('多数服务失败:', error);
  });

---

API 参考

API	说明
and	所有 Promise 成功，返回结果数组；任一失败则整体失败。
or	至少一个 Promise 成功，返回首个成功结果；全部失败则整体失败。
xor	有且仅有一个 Promise 成功，返回该结果；否则抛出 XOR_ERROR。
nand	所有 Promise 均失败，返回错误数组；任一成功则整体失败。
not	反转单个 Promise 的结果
majority	超过半数 Promise 成功，返回成功结果数组；否则整体失败。

---

资源链接

• GitHub 仓库：github.com/xier123456/…
• npm 包：www.npmjs.com/package/pro…
• Issue 跟踪：GitHub Issues

一、最核心的问题先回答

为什么我只在 pnpm-workspace.yaml 里写了 apps/*，
pnpm 就能知道 apps/web、apps/api 这些包，并把它们用起来？

答案只有一句话：

因为 pnpm 在启动时，
先用 Glob 规则找目录 → 再识别哪些是真正的包 → 在内存里记住它们的 name 和路径。

---

二、什么是 Glob？（一定要先懂这个）

1️⃣ Glob 是什么

Glob 是一种“用模式匹配文件路径”的规则

你每天其实都在用，比如：

ls *.js
ls apps/*

这里的 * 就是 Glob。

---

2️⃣ Glob 的“全称”是啥？

• 没有严格官方全称
• 约定俗成理解为：Global Pattern Matching
• 起源于 Unix Shell

👉 它不是 pnpm 发明的，是整个操作系统层面的东西。

---

3️⃣ Glob 能干什么？

Glob 只做一件事：

👉 在磁盘上找出“路径长得像”的文件或目录

⚠️ 重要：

• Glob 不懂什么是包
• Glob 不看 package.json
• 它只认路径形状

---

三、apps/* 到底是什么意思？

packages:
  - apps/*

这句话的真实含义是：

“请在项目根目录下，
找出所有路径形状像 apps/某个名字 的目录。”

比如磁盘上有：

apps/web
apps/api
apps/docs

Glob 匹配结果就是这三个。

---

四、pnpm 是怎么一步步工作的？（重点）

第一步：pnpm 判断是不是 Workspace

pnpm 启动时先看：

有没有 pnpm-workspace.yaml？

• 有 → Workspace 模式
• 没有 → 单包模式

⚠️ pnpm 只认这个文件。

---

第二步：Glob 展开（找目录）

pnpm 读取：

packages:
  - apps/*

然后：

• 使用 Glob 规则
• 遍历文件系统
• 找到所有匹配的目录：

apps/web
apps/api
apps/docs

⚠️ 此时 pnpm 还不知道谁是包。

---

第三步：识别“真正的包”

pnpm 接下来会逐个检查：

• apps/web → 有 package.json ✅
• apps/api → 有 package.json ✅
• apps/docs → 没有 ❌

只有有 package.json 的目录才算 workspace 包。

---

第四步：建立 Package Map（最关键）

pnpm 会读取每个包的 package.json 里的：

{
  "name": "@my-org/web",
  "version": "1.0.0"
}

然后在内存中建立一张表：

@my-org/web  -> apps/web
@my-org/api  -> apps/api
@my-org/ui   -> packages/ui

👉 这一步非常重要：

• pnpm 认的是 name
• 不是目录名
• 不是路径

---

五、pnpm 是什么时候把包“连起来”的？

❌ 不是扫描时

✅ 是安装依赖时

比如 apps/web/package.json：

{
  "dependencies": {
    "@my-org/ui": "^1.0.0"
  }
}

pnpm 在安装时会想：

1. 我要找 @my-org/ui
2. Workspace 里有没有同名包？
3. 有 → 用本地的
4. 没有 → 去 npm 仓库下载

👉 所谓“连起来”，本质是：

把依赖指向本地 workspace 包，而不是远程包

---

六、如果没有 pnpm-workspace.yaml 会怎样？

pnpm 会：

• ❌ 不扫描其他目录
• ❌ 不建立包映射表
• ❌ 不知道本地还有同名包

结果就是：

即使你本地有 packages/ui，
pnpm 也会去 npm 仓库下载一个同名包。

---

七、mac 上怎么自己“看到” Glob 在干嘛？

macOS 默认用的是 zsh，它天生支持 Glob。

你可以直接在终端试：

# 看 Glob 匹配了哪些目录
ls apps/*

再试：

# 看哪些是真正的包
ls apps/*/package.json

👉 这两步，和 pnpm 内部做的事情几乎一模一样。

---

八、最容易踩的坑（小白必看）

❌ 错误写法

packages:
  - apps

只会尝试：

apps/package.json

✅ 正确写法

packages:
  - apps/*

---

九、终极一句话总结（背下来就够了）

Glob 只是用来找目录的规则。
pnpm 用 Glob 找到目录后，再通过 package.json 判断哪些是包，
并把它们的 name 和路径记在内存里。
真正把包“连起来”的，是后面的依赖解析，而不是 Glob 本身。

---

pnpm Workspace 全流程图

┌────────────────────────────┐
│ 你运行 pnpm install        │
└─────────────┬──────────────┘
              │
              ▼
┌────────────────────────────┐
│ ① 是否存在 pnpm-workspace   │
│    .yaml ?                 │
└─────────────┬──────────────┘
      有      │        没有
      ▼       │         ▼
┌──────────────────┐   ┌──────────────────┐
│ Workspace 模式    │   │ 单包模式          │
└────────┬─────────┘   │（不扫描别的包）     │
         │             └──────────────────┘
         ▼
┌────────────────────────────┐
│ ② 读取 pnpm-workspace.yaml │
│    packages:               │
│    - apps/*                │
│    - packages/*            │
└─────────────┬──────────────┘
              ▼
┌────────────────────────────┐
│ ③ Glob 展开（找目录）        │
│ apps/* →                   │
│   apps/web                 │
│   apps/api                 │
│   apps/docs                │
└─────────────┬──────────────┘
              ▼
┌────────────────────────────┐
│ ④ 判断是否是包              │
│   有没有 package.json ?     │
│   web  ✅                  │
│   api  ✅                  │
│   docs ❌                  │
└─────────────┬──────────────┘
              ▼
┌────────────────────────────┐
│ ⑤ 读取 package.json        │
│   name / version           │
└─────────────┬──────────────┘
              ▼
┌────────────────────────────┐
│ ⑥ 建立 Package Map（内存）   │
│   @my-org/web → apps/web   │
│   @my-org/api → apps/api   │
└─────────────┬──────────────┘
              ▼
┌────────────────────────────┐
│ ⑦ 依赖解析（install 阶段）   │
│ web 依赖 @my-org/ui ?       │
│ → workspace 里有吗？         │
│ → 有 → 用本地包              │
│ → 没有 → 去 npm 仓库         │
└────────────────────────────┘

多数据源监听

在Vue 3中，watch 允许我们同时监听多个响应式数据源，当其中任意一个数据源发生变化时，都会触发回调函数。这在需要同步处理多个数据变化的场景中非常实用，比如表单多字段联动验证、多条件组合筛选等。

基本用法

我们可以将多个数据源（ref、reactive对象或getter函数）放入一个数组中，作为watch的第一个参数。回调函数的第一个参数是所有数据源的新值组成的数组，第二个参数是旧值组成的数组。

import { ref, watch } from 'vue'

// 定义多个响应式数据
const username = ref('')
const password = ref('')
const rememberMe = ref(false)

// 同时监听三个数据源
watch(
  [username, password, rememberMe],
  ([newUsername, newPassword, newRememberMe], [oldUsername, oldPassword, oldRememberMe]) => {
    console.log(`用户名从 ${oldUsername} 变为 ${newUsername}`)
    console.log(`密码从 ${oldPassword} 变为 ${newPassword}`)
    console.log(`记住我状态从 ${oldRememberMe} 变为 ${newRememberMe}`)
    
    // 实际场景中可以在这里进行表单验证
    if (newUsername && newPassword) {
      console.log('表单字段已填写完整')
    }
  }
)

执行流程

flowchart LR
A[定义多个响应式数据] --> B[将数据源放入数组作为watch的监听源]
B --> C[任意数据源发生变化]
C --> D[触发回调函数]
D --> E[解构新值和旧值数组，处理业务逻辑]

---

Getter函数监听

当我们需要监听的目标不是直接的响应式数据，而是基于响应式数据计算出的值时，可以使用getter函数作为watch的监听源。这种方式让我们能够灵活定义监听的计算逻辑。

基本用法

Getter函数需要返回我们想要监听的计算结果，当这个结果发生变化时，watch就会触发回调函数。

import { reactive, watch } from 'vue'

// 定义响应式状态对象
const cart = reactive({
  items: [
    { id: 1, name: 'Vue 3 实战教程', price: 59, quantity: 1 },
    { id: 2, name: 'Vuex 从入门到精通', price: 39, quantity: 2 }
  ]
})

// 监听购物车的总金额
watch(
  // Getter函数：计算总金额
  () => cart.items.reduce((total, item) => total + item.price * item.quantity, 0),
  (newTotal, oldTotal) => {
    console.log(`购物车总金额从 ${oldTotal} 元变为 ${newTotal} 元`)
    
    // 实际场景中可以在这里更新结算按钮状态或显示优惠信息
    if (newTotal >= 100) {
      console.log('满足满减条件，可享受10元优惠')
    }
  }
)

// 修改购物车商品数量，触发watch
cart.items[0].quantity = 2

执行流程

flowchart LR
A[定义响应式对象] --> B[创建getter函数，返回计算后的值]
B --> C[将getter函数作为watch的监听源]
C --> D[计算值发生变化]
D --> E[触发回调函数]
E --> F[处理新的计算结果]

---

数组监听

在Vue 3中监听数组需要注意一些细节，因为Vue的响应式系统对数组的处理和普通对象有所不同。默认情况下，watch会监听数组的引用变化和数组方法（如push、pop、splice等）的调用，但不会监听数组元素的直接索引修改。

往期文章归档

• Vue 3中watch监听ref和reactive的核心差异与注意事项是什么？
• Vue3中Watch与watchEffect的核心差异及适用场景是什么？
• Vue 3自定义指令如何赋能表单自动聚焦与防抖输入的高效实现？
• Vue3中如何优雅实现支持多绑定变量和修饰符的双向绑定组件？
• Vue 3表单验证如何从基础规则到异步交互构建完整验证体系？
• Vue3响应式系统如何支撑表单数据的集中管理、动态扩展与实时计算？
• Vue3跨组件通信中，全局事件总线与provide/inject该如何正确选择？
• Vue3表单事件处理：v-model如何实现数据绑定、验证与提交？
• Vue应用如何基于DOM事件传播机制与事件修饰符实现高效事件处理？
• Vue3中如何在调用事件处理函数时同时传递自定义参数和原生DOM事件？参数顺序有哪些注意事项？
• 从捕获到冒泡：Vue事件修饰符如何重塑事件执行顺序？
• Vue事件处理：内联还是方法事件处理器，该如何抉择？
• Vue事件绑定中v-on与@语法如何取舍？参数传递与原生事件处理有哪些实战技巧？
• Vue 3中列表排序时为何必须复制数组而非直接修改原始数据？
• Vue虚拟滚动如何将列表DOM数量从万级降至十位数？
• Vue3中v-if与v-for直接混用为何会报错？计算属性如何解决优先级冲突？
• 为何在Vue3递归组件中必须用v-if判断子项存在？
• Vue3列表渲染中，如何用数组方法与计算属性优化v-for的数据处理？
• Vue v-for的key：为什么它能解决列表渲染中的“玄学错误”？选错会有哪些后果？
• Vue3中v-for与v-if为何不能直接共存于同一元素？
• Vue3中v-if与v-show的本质区别及动态组件状态保持的关键策略是什么？
• Vue3中v-show如何通过CSS修改display属性控制条件显示？与v-if的应用场景该如何区分？
• Vue3条件渲染中v-if系列指令如何合理使用与规避错误？
• Vue3动态样式控制：ref、reactive、watch与computed的应用场景与区别是什么？
• Vue3中动态样式数组的后项覆盖规则如何与计算属性结合实现复杂状态样式管理？
• Vue浅响应式如何解决深层响应式的性能问题？适用场景有哪些？ - cmdragon's Blog
• Vue 3组合式API中ref与reactive的核心响应式差异及使用最佳实践是什么？ - cmdragon's Blog
• Vue 3组合式API中ref与reactive的核心响应式差异及使用最佳实践是什么？ - cmdragon's Blog
• Vue3响应式系统中，对象新增属性、数组改索引、原始值代理的问题如何解决？ - cmdragon's Blog
• Vue 3中watch侦听器的正确使用姿势你掌握了吗？深度监听、与watchEffect的差异及常见报错解析 - cmdragon's Blog
• Vue响应式声明的API差异、底层原理与常见陷阱你都搞懂了吗 - cmdragon's Blog
• Vue响应式声明的API差异、底层原理与常见陷阱你都搞懂了吗 - cmdragon's Blog
• 为什么Vue 3需要ref函数？它的响应式原理与正确用法是什么？ - cmdragon's Blog
• Vue 3中reactive函数如何通过Proxy实现响应式？使用时要避开哪些误区？ - cmdragon's Blog
• Vue3响应式系统的底层原理与实践要点你真的懂吗？ - cmdragon's Blog
• Vue 3模板如何通过编译三阶段实现从声明式语法到高效渲染的跨越 - cmdragon's Blog
• 快速入门Vue模板引用：从收DOM“快递”到调子组件方法，你玩明白了吗？ - cmdragon's Blog
• 快速入门Vue模板里的JS表达式有啥不能碰？计算属性为啥比方法更能打？ - cmdragon's Blog
• 快速入门Vue的v-model表单绑定：语法糖、动态值、修饰符的小技巧你都掌握了吗？ - cmdragon's Blog
• 快速入门Vue3事件处理的挑战题：v-on、修饰符、自定义事件你能通关吗？ - cmdragon's Blog
• 快速入门Vue3的v-指令：数据和DOM的“翻译官”到底有多少本事？ - cmdragon's Blog
• 快速入门Vue3，插值、动态绑定和避坑技巧你都搞懂了吗？ - cmdragon's Blog
• 想让PostgreSQL快到飞起？先找健康密码还是先换引擎？ - cmdragon's Blog
• 想让PostgreSQL查询快到飞起？分区表、物化视图、并行查询这三招灵不灵？ - cmdragon's Blog
• 子查询总拖慢查询？把它变成连接就能解决？ - cmdragon's Blog
• PostgreSQL全表扫描慢到崩溃？建索引+改查询+更统计信息三招能破？ - cmdragon's Blog
• 复杂查询总拖后腿？PostgreSQL多列索引+覆盖索引的神仙技巧你get没？ - cmdragon's Blog
• 只给表子集建索引？用函数结果建索引？PostgreSQL这俩操作凭啥能省空间又加速？ - cmdragon's Blog
• B-tree索引像字典查词一样工作？那哪些数据库查询它能加速，哪些不能？ - cmdragon's Blog
• 想抓PostgreSQL里的慢SQL？pg_stat_statements基础黑匣子和pg_stat_monitor时间窗，谁能帮你更准揪出性能小偷？ - cmdragon's Blog
• PostgreSQL的“时光机”MVCC和锁机制是怎么搞定高并发的？ - cmdragon's Blog
• PostgreSQL性能暴涨的关键？内存IO并发参数居然要这么设置？ - cmdragon's Blog
• 大表查询慢到翻遍整个书架？PostgreSQL分区表教你怎么“分类”才高效
• PostgreSQL 查询慢？是不是忘了优化 GROUP BY、ORDER BY 和窗口函数？ - cmdragon's Blog
• PostgreSQL里的子查询和CTE居然在性能上“掐架”？到底该站哪边？ - cmdragon's Blog
• PostgreSQL选Join策略有啥小九九？Nested Loop/Merge/Hash谁是它的菜？ - cmdragon's Blog
• PostgreSQL新手SQL总翻车？这7个性能陷阱你踩过没？ - cmdragon's Blog
• PostgreSQL索引选B-Tree还是GiST？“瑞士军刀”和“多面手”的差别你居然还不知道？ - cmdragon's Blog
• 想知道数据库怎么给查询“算成本选路线”？EXPLAIN能帮你看明白？ - cmdragon's Blog
• PostgreSQL处理SQL居然像做蛋糕？解析到执行的4步里藏着多少查询优化的小心机？ - cmdragon's Blog
• PostgreSQL备份不是复制文件？物理vs逻辑咋选？误删还能精准恢复到1分钟前？ - cmdragon's Blog
• 转账不翻车、并发不干扰，PostgreSQL的ACID特性到底有啥魔法？ - cmdragon's Blog
• 银行转账不白扣钱、电商下单不超卖，PostgreSQL事务的诀窍是啥？ - cmdragon's Blog
• PostgreSQL里的PL/pgSQL到底是啥？能让SQL从“说目标”变“讲步骤”？ - cmdragon's Blog
• PostgreSQL视图不存数据？那它怎么简化查询还能递归生成序列和控制权限？ - cmdragon's Blog
• PostgreSQL索引这么玩，才能让你的查询真的“飞”起来？ - cmdragon's Blog
• PostgreSQL的表关系和约束，咋帮你搞定用户订单不混乱、学生选课不重复？ - cmdragon's Blog
• PostgreSQL查询的筛子、排序、聚合、分组？你会用它们搞定数据吗？ - cmdragon's Blog
• PostgreSQL数据类型怎么选才高效不踩坑？ - cmdragon's Blog
• 想解锁PostgreSQL查询从基础到进阶的核心知识点？你都get了吗？ - cmdragon's Blog
• PostgreSQL DELETE居然有这些操作？返回数据、连表删你试过没？ - cmdragon's Blog
• PostgreSQL UPDATE语句怎么玩？从改邮箱到批量更新的避坑技巧你都会吗？ - cmdragon's Blog
• PostgreSQL插入数据还在逐条敲？批量、冲突处理、返回自增ID的技巧你会吗？ - cmdragon's Blog
• PostgreSQL的“仓库-房间-货架”游戏，你能建出电商数据库和表吗？ - cmdragon's Blog
• PostgreSQL 17安装总翻车？Windows/macOS/Linux避坑指南帮你搞定？ - cmdragon's Blog
• 能当关系型数据库还能玩对象特性，能拆复杂查询还能自动管库存，PostgreSQL凭什么这么香？ - cmdragon's Blog
• 给接口加新字段又不搞崩老客户端？FastAPI的多版本API靠哪三招实现？ - cmdragon's Blog
• 流量突增要搞崩FastAPI？熔断测试是怎么防系统雪崩的？ - cmdragon's Blog
• FastAPI秒杀库存总变负数？Redis分布式锁能帮你守住底线吗 - cmdragon's Blog
• FastAPI的CI流水线怎么自动测端点，还能让Allure报告美到犯规？ - cmdragon's Blog
• 如何用GitHub Actions为FastAPI项目打造自动化测试流水线？ - cmdragon's Blog

免费好用的热门在线工具

• 文件格式转换器 - 应用商店 | By cmdragon
• M3U8在线播放器 - 应用商店 | By cmdragon
• 快图设计 - 应用商店 | By cmdragon
• 高级文字转图片转换器 - 应用商店 | By cmdragon
• RAID 计算器 - 应用商店 | By cmdragon
• 在线PS - 应用商店 | By cmdragon
• Mermaid 在线编辑器 - 应用商店 | By cmdragon
• 数学求解计算器 - 应用商店 | By cmdragon
• 智能提词器 - 应用商店 | By cmdragon
• 魔法简历 - 应用商店 | By cmdragon
• Image Puzzle Tool - 图片拼图工具 | By cmdragon
• 字幕下载工具 - 应用商店 | By cmdragon
• 歌词生成工具 - 应用商店 | By cmdragon
• 网盘资源聚合搜索 - 应用商店 | By cmdragon
• ASCII字符画生成器 - 应用商店 | By cmdragon
• JSON Web Tokens 工具 - 应用商店 | By cmdragon
• Bcrypt 密码工具 - 应用商店 | By cmdragon
• GIF 合成器 - 应用商店 | By cmdragon
• GIF 分解器 - 应用商店 | By cmdragon
• 文本隐写术 - 应用商店 | By cmdragon
• CMDragon 在线工具 - 高级AI工具箱与开发者套件 | 免费好用的在线工具
• 应用商店 - 发现1000+提升效率与开发的AI工具和实用程序 | 免费好用的在线工具
• CMDragon 更新日志 - 最新更新、功能与改进 | 免费好用的在线工具
• 支持我们 - 成为赞助者 | 免费好用的在线工具
• AI文本生成图像 - 应用商店 | 免费好用的在线工具
• 临时邮箱 - 应用商店 | 免费好用的在线工具
• 二维码解析器 - 应用商店 | 免费好用的在线工具
• 文本转思维导图 - 应用商店 | 免费好用的在线工具
• 正则表达式可视化工具 - 应用商店 | 免费好用的在线工具
• 文件隐写工具 - 应用商店 | 免费好用的在线工具
• IPTV 频道探索器 - 应用商店 | 免费好用的在线工具
• 快传 - 应用商店 | 免费好用的在线工具
• 随机抽奖工具 - 应用商店 | 免费好用的在线工具
• 动漫场景查找器 - 应用商店 | 免费好用的在线工具
• 时间工具箱 - 应用商店 | 免费好用的在线工具
• 网速测试 - 应用商店 | 免费好用的在线工具
• AI 智能抠图工具 - 应用商店 | 免费好用的在线工具
• 背景替换工具 - 应用商店 | 免费好用的在线工具
• 艺术二维码生成器 - 应用商店 | 免费好用的在线工具
• Open Graph 元标签生成器 - 应用商店 | 免费好用的在线工具
• 图像对比工具 - 应用商店 | 免费好用的在线工具
• 图片压缩专业版 - 应用商店 | 免费好用的在线工具
• 密码生成器 - 应用商店 | 免费好用的在线工具
• SVG优化器 - 应用商店 | 免费好用的在线工具
• 调色板生成器 - 应用商店 | 免费好用的在线工具
• 在线节拍器 - 应用商店 | 免费好用的在线工具
• IP归属地查询 - 应用商店 | 免费好用的在线工具
• CSS网格布局生成器 - 应用商店 | 免费好用的在线工具
• 邮箱验证工具 - 应用商店 | 免费好用的在线工具
• 书法练习字帖 - 应用商店 | 免费好用的在线工具
• 金融计算器套件 - 应用商店 | 免费好用的在线工具
• 中国亲戚关系计算器 - 应用商店 | 免费好用的在线工具
• Protocol Buffer 工具箱 - 应用商店 | 免费好用的在线工具
• IP归属地查询 - 应用商店 | 免费好用的在线工具
• 图片无损放大 - 应用商店 | 免费好用的在线工具
• 文本比较工具 - 应用商店 | 免费好用的在线工具
• IP批量查询工具 - 应用商店 | 免费好用的在线工具
• 域名查询工具 - 应用商店 | 免费好用的在线工具
• DNS工具箱 - 应用商店 | 免费好用的在线工具
• 网站图标生成器 - 应用商店 | 免费好用的在线工具
• XML Sitemap

监听数组整体变化

当使用数组方法修改数组时，watch会自动触发：

import { ref, watch } from 'vue'

const todoList = ref(['学习Vue 3', '编写项目实战'])

// 监听数组整体变化
watch(todoList, (newList, oldList) => {
  console.log('待办事项列表发生变化：', newList)
})

// 使用数组方法修改数组，触发watch
todoList.value.push('优化代码性能')
todoList.value.pop()

监听数组内部元素变化

如果需要监听数组元素的直接修改（如arr[0] = '新值'），需要开启deep选项：

import { ref, watch } from 'vue'

const numbers = ref([1, 2, 3, 4])

// 开启deep选项，监听数组内部元素变化
watch(numbers, (newNumbers, oldNumbers) => {
  console.log('数组元素发生变化：', newNumbers)
}, { deep: true })

// 直接修改数组元素，触发watch
numbers.value[0] = 100

执行流程

flowchart LR
A[定义响应式数组] --> B[使用watch监听数组，可选开启deep]
B --> C[修改数组]
C --> D{修改方式?}
D -->|数组方法| E[触发watch回调]
D -->|索引修改| F{是否开启deep?}
F -->|是| E
F -->|否| G[不触发watch回调]

---

课后Quiz

问题1

如何在Vue 3中同时监听多个响应式数据的变化？请写出代码示例。

答案解析： 可以将多个数据源放入数组中作为watch的第一个参数，回调函数会接收新值数组和旧值数组：

import { ref, watch } from 'vue'

const name = ref('')
const age = ref(0)

watch(
  [name, age],
  ([newName, newAge], [oldName, oldAge]) => {
    console.log(`姓名从 ${oldName} 变为 ${newName}`)
    console.log(`年龄从 ${oldAge} 变为 ${newAge}`)
  }
)

问题2

当需要监听响应式对象中多个属性的计算结果时，应该使用什么方式？请写出代码示例。

答案解析： 使用getter函数作为watch的监听源，在getter函数中计算需要监听的结果：

import { reactive, watch } from 'vue'

const product = reactive({
  stock: 100,
  sales: 30
})

// 监听剩余库存
watch(
  () => product.stock - product.sales,
  (newStock, oldStock) => {
    console.log(`剩余库存从 ${oldStock} 变为 ${newStock}`)
  }
)

问题3

为什么直接修改数组的索引元素时，watch默认不会触发？如何解决这个问题？

答案解析： Vue的响应式系统默认不会监听数组的索引修改，因为这在性能上是低效的。解决方法有两种：

1. 开启deep选项，深度监听数组内部元素变化
2. 使用Vue提供的数组方法（如push、splice等）来修改数组

---

常见报错解决方案

报错1：watch source must be a ref, reactive object, getter function, or array of these

• 原因：watch的监听源类型不正确，不是Vue支持的响应式数据源类型。
• 解决方法：确保监听源是ref、reactive对象、getter函数或这些类型的数组。例如，如果你想监听普通变量，需要先将其转换为ref：

// 错误用法：监听普通变量
let count = 0
watch(count, () => { /* ... */ })

// 正确用法：转换为ref
const count = ref(0)
watch(count, () => { /* ... */ })

报错2：数组元素修改后watch不触发

• 原因：直接修改数组索引元素，Vue默认不监听这种变化。
• 解决方法：开启deep选项，或者使用数组方法修改数组：

// 方法1：开启deep选项
watch(numbers, () => { /* ... */ }, { deep: true })

// 方法2：使用数组方法
numbers.value.splice(0, 1, 100)

报错3：Cannot read property 'value' of undefined

• 原因：在getter函数或回调函数中访问了未定义的响应式属性。
• 解决方法：确保所有访问的属性都已正确定义，或者添加可选链操作符：

// 错误用法：访问未定义的属性
watch(() => user.address.city, () => { /* ... */ })

// 正确用法：添加可选链
watch(() => user?.address?.city, () => { /* ... */ })

---

参考链接

参考链接：vuejs.org/guide/essen…