架构篇(一)：告别MVC/MVP，为何“组件化”是现代前端的唯一答案？

架构篇(一)：告别MVC/MVP，为何“组件化”是现代前端的唯一答案？

引子：一个困扰前端工程师的“幽灵”

在上一章《序章：抛弃UI，我们来构建一个“看不见”的前端应用》中，我们从零开始构建了一个纯逻辑的任务调度器。我们定义了“任务”（Task），它们有依赖关系，能自动按序执行并传递数据。整个过程如行云流水，清晰而高效。

但是，一个问题油然而生：我们构建的这个模型，和传统的前端架构模式，比如大名鼎鼎的MVC（Model-View-Controller）或者它的变种MVP、MVVM，到底是什么关系？是我们“发明”了新东西，还是在无意中“重蹈覆辙”？

这并非杞人忧天。前端发展的历史，在某种程度上，就是一部与“复杂性”搏斗的历史。而架构模式，正是我们对抗复杂性的核心武器。从最初的JSP/PHP前后端混合开发，到Backbone.js带来的MVC，再到Angular的MVVM，以及最终React/Vue引领的组件化时代，我们一直在寻找管理代码、分离关注点的最佳方式。

今天，我们就要正面回答这个问题：为什么说，在现代前端领域，“组件化”思想已经取得了决定性的胜利，成为了那个唯一的答案？我们将不只是罗列概念，而是要深入“关注点分离”（Separation of Concerns, SoC）这一软件工程的基石原则，从根本上论证其合理性。

准备好，这不仅仅是一次历史回顾，更是一场对前端架构思想的深度解剖。

第一幕：古典时代 - MVC的“美好承诺”与“残酷现实”

在前端领域的上古时代（大约是jQuery大行其道的2010年左右），开发者面临的最大痛苦是：业务逻辑、数据和UI代码混杂在一起。一个典型的jQuery回调函数可能长这样：

// 一个“上古”的回调函数
$('#submit-button').click(function() {// 1. 从UI获取数据 (View -> Controller)var username = $('#username').val();var password = $('#password').val();// 2. 校验逻辑 (Controller)if (username.length < 4) {// 3. 直接操作DOM更新UI (Controller -> View)$('#error-message').text('用户名不能少于4位').show();return;}// 4. 业务逻辑与数据请求 (Controller -> Model)$.ajax({url: '/api/login',method: 'POST',data: { username: username, password: password },success: function(response) {// 5. 更新数据 (Model)// 假设我们有一个全局对象来存用户状态window.currentUser = response.user;// 6. 再次直接操作DOM (Controller -> View)$('#user-panel').text('欢迎, ' + response.user.name);$('#login-form').hide();},error: function(err) {// 7. 又一次操作DOM (Controller -> View)$('#error-message').text('登录失败: ' + err.responseJSON.message).show();}});
});

这段代码就是一碗“意大利面”，所有东西都搅和在一起。修改一个UI元素，可能会影响业务逻辑；调整一个API请求，可能需要重写大段的DOM操作。维护成本极高，代码复用几乎为零。

就在这时，源自Smalltalk，在Ruby on Rails等后端框架中大放异彩的MVC模式，被Backbone.js等早期框架引入了前端。

MVC的核心思想：美好的“三权分立”

MVC的承诺非常诱人：它试图将一个应用清晰地划分为三个部分，实现“关注点分离”。

  1. Model（模型）：负责管理应用的数据和业务逻辑。它不关心数据如何展示，只负责获取、存储、更新数据，并执行相关的业务规则。比如，在我们的登录场景里，Model应该只包含login(username, password)方法，并维护当前用户的状态。

  2. View（视图）：负责展示数据，即用户界面。它应该是“哑”的，只从Model获取数据并渲染出来。它不包含任何业务逻辑。当用户在View上进行操作（如点击按钮）时，它会通知Controller。

  3. Controller（控制器）：作为Model和View之间的协调者。它接收来自View的用户输入，调用相应的Model方法来处理业务逻辑，然后根据Model的更新结果，选择合适的View来展示。

这个模型在理论上看起来天衣无缝。数据流是这样的：

用户操作
View
Controller
Model

用户在View上操作，View通知Controller，Controller更新Model，Model发生变化，View监听到变化并更新自己。

前端的残酷现实：失控的“C”与混乱的“V”

然而，这个在后端运行良好的模式，在前端却水土不服。核心原因在于：前端的“View”远比后端的复杂，它自身就充满了大量的状态和交互逻辑。

一个网页应用，不是一个单一的View，而是由无数个UI元素（按钮、表单、对话框、图表…）组成的复杂层级结构。这导致了几个致命问题：

  1. Controller的膨胀（Fat Controller）：由于View非常复杂，Controller需要做的事情太多了。它不仅要处理业务逻辑的调用，还要负责监听无数个DOM事件，管理View的各种显示/隐藏状态，甚至还要手动更新DOM。很快，Controller就变成了新的“意大利面”。

  2. View与Controller的紧密耦合：在实践中，View和Controller几乎总是成对出现的，难以分割。一个LoginView必然对应一个LoginController。因为View上的任何一个DOM元素的变化，都需要Controller来响应。它们之间的通信变得极其频繁和复杂，所谓的“分离”名存实亡。

  3. 数据流的混乱：随着应用复杂度的提升，多个Model和多个View之间会形成一张混乱的网。一个Model的改变可能会触发多个View的更新；一个View的操作也可能影响多个Model。数据流不再是清晰的环路，而是一张蜘蛛网，调试和追踪变得异常困难。

让我们用上一章的任务调度器来思考一下：

如果用MVC来组织我们的代码，会是什么样？

  • Model: fetchUser, fetchOrders这些API调用和数据处理逻辑，属于Model。
  • View: 在我们的“看不见”应用里，可以想象成是最终输出结果的那个部分，比如console.log('最终金额是：', total)。
  • Controller: Scheduler类本身，以及main.js里注册和编排任务的逻辑，都扮演了Controller的角色。它接收“运行”指令，调用Model（任务工厂），然后驱动View（最终输出）。

看起来好像还行？但问题在于，当任务（功能）增多时，main.js这个“主控制器”会变得越来越臃肿。如果我们要增加一个新的、完全独立的功能，比如“生成报告”，我们就得在main.js里增加更多的注册和编排逻辑，它和“计算总额”的逻辑混在一起。

更重要的是，“计算总额”这个功能本身，它的内部逻辑（获取用户 -> 获取订单 -> 计算）是高度内聚的，但被MVC硬生生拆散到了M、V、C三个地方。这违背了软件设计中另一个重要原则：高内聚，低耦合。

MVC在前端的尝试，最终证明了它并不是解决复杂UI问题的银弹。我们需要一种新的、更适合UI场景的架构模式。

第二幕：进化与改良 - MVP与MVVM的探索

开发者们很快意识到了纯粹MVC的弊病，于是开始进行改良，诞生了两个重要的变种：MVP和MVVM。

MVP（Model-View-Presenter）：为解耦而生

MVP模式的核心目标是彻底切断View和Model之间的直接联系。

  • Model：和MVC一样，负责数据和业务逻辑。
  • View：变得更加“被动”。它只负责UI的渲染，并向上暴露一系列接口（例如showLoading(), displayData(data), showError(message))供Presenter调用。同时，它将所有的用户操作都委托给Presenter处理。
  • Presenter（主持人）：取代了Controller，成为中心协调者。它从Model获取数据，然后调用View的接口来更新UI。它处理所有的业务逻辑和UI逻辑。

数据流变成了这样：

Model
Presenter
View
数据
命令
数据/业务
处理逻辑
DOM
用户操作

所有的数据流都必须经过Presenter。View不再关心数据如何变化，它只听从Presenter的命令。

优点：

  • 高度解耦：View和Model完全分离，你可以为一个Presenter轻松地替换不同的View（比如，一套逻辑可以用于Web页面，也可以用于移动端原生UI）。
  • 可测试性增强：由于View变得非常薄，并且有清晰的接口，Presenter的逻辑可以脱离UI进行单元测试，这是一个巨大的进步。

缺点：

  • Presenter的膨胀：和Controller一样，随着业务复杂度的增加，Presenter也容易变得臃肿不堪。因为它承担了太多的角色：业务逻辑、UI逻辑、数据格式化等等。
  • 大量的模板代码：由于View的所有更新都必须通过Presenter调用接口来完成，你会写下大量类似presenter.getView().showSomething()这样的胶水代码，显得非常繁琐。

MVVM（Model-View-ViewModel）：数据绑定的魔法

在MVP的基础上，MVVM（由WPF/Silverlight带入前端，后被AngularJS发扬光光大）引入了一个革命性的东西：数据绑定（Data Binding）。

  • Model：依然是数据和业务逻辑。
  • View：依然是UI。
  • ViewModel：这是新的核心。它很像Presenter，负责提供数据和处理逻辑。但它不直接操作View。
  • Binder（绑定器）：这是隐藏在框架背后的“魔法”。它在View和ViewModel之间建立了一个双向的通道。

数据流是这样的：

graph TDsubgraph ViewA[用户操作]endsubgraph ViewModelB[数据/命令]endsubgraph ModelC[业务/数据源]endA -- (双向绑定) --> B;B --> C;C -- 数据 --> B;

工作流程：

  1. ViewModel从Model获取数据，并将其暴露为一系列属性（比如viewModel.username）。
  2. View通过一种特殊的语法（比如Angular的ng-model="viewModel.username"）声明式地“绑定”到ViewModel的属性上。
  3. 当ViewModel的属性变化时，Binder会自动更新View中对应的UI元素。
  4. 反过来，当用户在View中修改了UI元素（比如在输入框里打字），Binder也会自动更新ViewModel中对应的属性。

优点：

  • 解放DOM操作：开发者几乎不需要再写任何手动更新DOM的代码，大大提升了开发效率。
  • 声明式UI：你只需要在模板里声明“这里应该显示什么数据”，而不用关心“数据变化后如何更新到这里”。

缺点：

  • “魔法”的代价：数据绑定虽然强大，但也像一个黑盒。一旦出现问题（比如性能瓶颈、意外的循环更新），调试起来会非常痛苦，因为你不知道数据是如何在底层流动的。
  • 过于复杂的ViewModel：ViewModel依然可能变得非常庞大，因为它包含了UI状态、业务逻辑、数据转换等所有东西。
  • 难以驾驭的双向绑定：在复杂场景下，双向绑定很容易导致数据流向混乱，你很难追踪一个状态的改变究竟是由哪个操作引起的。

小结一下：从MVC到MVP再到MVVM，我们看到了一条清晰的进化路线：试图将UI逻辑与业务逻辑分离，并不断尝试用更自动化的方式来同步数据和视图。

然而，它们都有一个共同的局限性：它们依然在用一种“宏观”的、自顶向下的方式来划分应用。它们都基于一个隐含的假设：应用可以被清晰地划分为M、V、C（或P、VM）这几个“层”。

但前端的本质，是一个由可复用的UI零件组装起来的整体。一个按钮、一个表单、一个用户头像卡片，它们本身就包含了各自的M、V、C。硬要用一个全局的M、V、C去套它们，就像是用设计一栋大楼的图纸去指导如何制造一颗螺丝钉，显得格格不入。

是时候打破这种“分层”的思维定式了。

第三幕：革命的到来 - 组件化的“唯一答案”

React（以及后来的Vue）带来的革命，其核心并非Virtual DOM或JSX，而是一种全新的思考方式：以组件（Component）为核心，自下而上地构建应用。

组件化思想彻底抛弃了“水平分层”（MVC/MVP/MVVM），转向了**“垂直分割”**。

什么是垂直分割？

它认为，一个功能相关的所有东西——包括它的数据（Model）、视图（View） 和 逻辑（Controller）——都应该被封装在一个高内聚的单元里，这个单元就是“组件”。

我们来重新审视一下那个“用户头像卡片”的例子：

  • 数据（Model）：用户的头像URL、姓名、在线状态。这些数据可能来自props，也可能是组件内部的状态。
  • 视图（View）：渲染出来的HTML结构，包括<img>、<span>和那个表示在线状态的小绿点。
  • 逻辑（Controller）：当鼠标悬浮时显示用户详情、点击头像时跳转到用户主页的逻辑。

在组件化思想中，所有这些东西都应该被放在同一个地方（比如一个UserAvatar.jsx文件里）。这个组件对外只暴露必要的接口（props），而将其内部的实现细节完全隐藏起来。

组件化如何解决古典模式的痛点？

  1. 解决了Controller/Presenter/ViewModel的膨胀问题：由于逻辑被分散到了各个小组件内部，不再存在一个“上帝”般的中心控制器。每个组件只关心自己的事情，极大地降低了单个模块的复杂度。

  2. 真正实现了“高内聚、低耦合”：功能相关的一切都被封装在一起，这是“高内聚”。组件之间只通过定义良好的props和事件进行通信，这是“低耦合”。

  3. 带来了前所未有的“可复用性”：一个设计良好的组件，可以像积木一样，在应用的任何地方复用，甚至可以发布到npm，在不同项目间共享。这是MVC等模式难以企及的。

  4. 清晰的单向数据流：React推广的“单向数据流”原则（数据总是从父组件通过props流向子组件）从根本上解决了MVVM双向绑定可能带来的混乱。数据流变得可预测、可追溯。

用“看不见”的应用来理解“组件化”

现在，让我们回到第一章构建的任务调度器，用“组件化”的思想来重构它。

在之前的模型里，我们有三个扁平的“任务”：getUser、getOrders、calculateTotal。我们是在一个全局的main.js里把它们“编排”起来的。

现在，我们把calculateTotal这个“最终目标”看作一个顶层组件。这个组件为了完成自己的任务，它需要一些子组件（或者说，服务）来帮助它。

  • OrderService 组件: 它专门负责与订单相关的逻辑。它内部可能依赖UserService。
  • UserService 组件: 它专门负责与用户相关的逻辑。

注意，这里的“组件”是纯逻辑的，没有UI。它们就像是面向对象编程里的“服务类”。

让我们重新组织一下代码：

services.js (我们的逻辑组件库)

// CSDN @ 你的用户名
// 系列: 前端内功修炼：从零构建一个“看不见”的应用
//
// 文件: /src/v2/services.js
// 描述: 将任务封装成高内聚的“逻辑组件”（服务）。// --- 模拟底层API ---
const mockUser = { id: 'user-001', name: 'CodeMaster' };
const mockOrders = [{ id: 'order-101', userId: 'user-001', amount: 150 },{ id: 'order-102', userId: 'user-001', amount: 200 },{ id: 'order-103', userId: 'user-001', amount: 50 },
];const fetchUser = (userId) => new Promise(resolve => setTimeout(() => resolve(mockUser), 500));
const fetchOrders = (userId) => new Promise(resolve => setTimeout(() => resolve(mockOrders.filter(o => o.userId === userId)), 800));/*** UserService: 一个逻辑组件，封装所有与用户相关的操作。* 在这个例子里，它非常简单。*/
class UserService {// 这是一个方法，可以看作组件的“能力”async getUser(userId) {console.log(`[UserService] Getting user: ${userId}`);// 内部实现了数据获取、缓存、错误处理等逻辑const user = await fetchUser(userId);return user;}
}/*** OrderService: 另一个逻辑组件，封装订单逻辑。* 它“组合”了UserService。*/
class OrderService {// 构造函数注入依赖，这是组件间组合的一种方式constructor(userService) {if (!userService) {throw new Error('OrderService requires a UserService instance.');}this.userService = userService;}async getOrdersForUser(userId) {console.log(`[OrderService] Getting orders for user: ${userId}`);// 这里没有直接调用API，而是依赖了另一个组件// 但它并不关心userService.getUser的内部实现const user = await this.userService.getUser(userId);if (!user) {throw new Error('User not found, cannot get orders.');}const orders = await fetchOrders(user.id);return orders;}
}/*** TotalCalculatorComponent: 我们的顶层“应用”组件。* 它组合了OrderService。*/
class TotalCalculatorComponent {constructor(orderService) {if (!orderService) {throw new Error('TotalCalculatorComponent requires an OrderService instance.');}this.orderService = orderService;}// 这是该组件的核心功能async calculateForUser(userId) {console.log(`[TotalCalculatorComponent] Starting calculation for user: ${userId}`);const orders = await this.orderService.getOrdersForUser(userId);if (!Array.isArray(orders)) {throw new Error('Invalid orders data received.');}const total = orders.reduce((sum, order) => sum + order.amount, 0);console.log(`[TotalCalculatorComponent] Calculation finished. Total: ${total}`);return total;}
}// 导出这些“逻辑组件”
module.exports = {UserService,OrderService,TotalCalculatorComponent
};

main.js (应用的“组装文件”或“入口文件”)

// CSDN @ 你的用户名
// 系列: 前端内功修炼：从零构建一个“看不见”的应用
//
// 文件: /src/v2/main.js
// 描述: “组装”我们的逻辑组件，并运行应用。const {UserService,OrderService,TotalCalculatorComponent
} = require('./services');async function main() {console.log('--- V2 Application Start ---');// 1. “实例化”我们的组件（服务）// 这对应React/Vue中<App />的渲染过程const userService = new UserService();const orderService = new OrderService(userService); // 依赖注入const app = new TotalCalculatorComponent(orderService); // 注入依赖// 2. 运行我们的“应用”// 这对应用户打开页面，触发了顶层组件的渲染try {const finalAmount = await app.calculateForUser('user-001');console.log('\n✅ FINAL RESULT: Total spending is', finalAmount);} catch (error) {console.error('\n❌ An error occurred:', error);}console.log('--- V2 Application End ---');
}main();

运行node main.js，输出结果的逻辑和第一章完全一样。但代码的组织形式发生了根本性的变化：

  1. 封装：UserService封装了所有用户相关的细节，OrderService封装了订单逻辑。TotalCalculatorComponent不需要知道fetchUser或fetchOrders的存在，它只需要知道orderService有一个getOrdersForUser方法。

  2. 组合：我们像搭积木一样，用UserService组装出OrderService，再用OrderService组装出TotalCalculatorComponent。这就是组合优于继承原则的体现。

  3. 依赖注入：我们通过构造函数将一个组件的依赖（其他组件）“注入”进去。这是一种非常常见的、实现解耦的设计模式。

我们不再需要一个全局的、万能的Scheduler了。调度的逻辑，被内化到了组件的组合关系之中。 TotalCalculatorComponent“调用”OrderService，就隐含了调度的顺序。

这就是组件化的威力：它将应用的复杂性，从“流程的复杂性”转化为“结构的复杂性”。管理流程是困难的、反直觉的；而管理结构，是我们人类大脑更擅长的事情。我们可以画出组件之间的依赖图，就像画一张组织架构图一样，清晰直观。

main.js
注入
注入
注入
调用
调用
实例化
UserService
OrderService
TotalCalculatorComponent

这张图，就是我们“看不见”应用的架构图。它清晰地展示了数据的流动方向和控制权的转移方向。

结论：为什么说“组件化”是唯一答案

回顾我们的历程，从混乱的jQuery回调，到MVC的分层，到MVP/MVVM的改良，再到组件化的革命，我们一直在追求“关注点分离”的终极理想。

  • MVC/MVP/MVVM 试图通过水平分层来实现SoC。它们在逻辑相对简单的应用中表现尚可，但在面对复杂、可复用、交互密集的现代UI时，这种分层思想本身成为了瓶颈。它强行将高内聚的功能拆散，导致了低内聚和高耦合。

  • 组件化 则通过垂直分割来达到目的。它将一个功能所需的所有元素（数据、视图、逻辑）封装成一个独立的、可复用的单元。这天然地实现了高内聚。组件之间通过清晰的接口（props/events）通信，实现了低耦合。

可以说，组件化是“关注点分离”原则在UI开发领域最自然、最有效的体现。

它将应用的构建方式，从“编写一段又一段的处理流程”，变成了“组装一个又一个的功能模块”。这种思维上的转变，是前端开发成熟的标志，也是我们能够驾驭今天如此复杂的Web应用的关键。

当然，组件化并非没有挑战：如何划分组件的粒度？如何处理跨组件的状态共享？这些问题催生了状态管理库（Redux, Vuex, Jotai）、Hook等新的技术。而这些，也正是我们这个系列后续要深入探讨的内容。

核心要点：

  1. 前端架构的核心目标是有效实现“关注点分离”（SoC）以对抗复杂性。
  2. MVC/MVP/MVVM等传统模式采用“水平分层”思想，试图将应用分为M、V、C等层面，但在复杂UI场景下会导致“控制器膨胀”和“功能被拆散”等问题。
  3. 组件化采用“垂直分割”思想，将高内聚的功能（数据、视图、逻辑）封装在独立的组件单元中，是SoC在UI开发中更自然的体现。
  4. 通过“组合”和“依赖注入”来构建应用，将“流程的复杂性”转化为更易于管理的“结构的复杂性”，是组件化思想的核心优势。

在下一章 《渲染篇(一)：从零实现一个“微型React”：Virtual DOM的真面目》 中，我们将为我们这些“纯逻辑”的组件，赋予“看得见”的能力。我们将亲手实现createElement函数，用纯JS对象来描述UI结构，揭开Virtual DOM的神秘面纱。这会是连接我们“看不见”的世界和“看得见”的世界的第一座桥梁。敬请期待！

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若转载，请注明出处：http://www.pswp.cn/web/90682.shtml
繁体地址，请注明出处：http://hk.pswp.cn/web/90682.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

数组内存学习

数组内存学习

一、内存简介&#xff1a;1.内存分为5块&#xff1a;a.栈&#xff08;Stack&#xff09;主要运行方法&#xff0c;方法的运行都会进入栈内存运行&#xff0c;云南行完毕之后&#xff0c;需要“弹栈”&#xff0c;为了腾空间。b.堆&#xff08;Heap&#xff09;保存的是对象&…
阅读更多...
验证 GitHub Pages 的自定义域（Windows）

验证 GitHub Pages 的自定义域（Windows）

验证 GitHub Pages 的自定义域 您可以通过验证您的域来提高自定义域的安全性并避免接管攻击。 谁可以使用此功能？ GitHub Pages 在公共存储库中提供 GitHub Free 和 GitHub Free for organizations，在公共和私有存储库中提供 GitHub Pro、GitHub Team、GitHub Enterprise Cl…
阅读更多...
数字化转型 - 企业数字化建设的几点思考

数字化转型 - 企业数字化建设的几点思考

关于企业数字化建设的几点思考工业软件领军人才的培训课中&#xff0c;如上的一个PPT&#xff0c;给人以许多反思。一是看企业成功的数字化案例时&#xff0c;也许只看到别人面上的东西&#xff0c;可能还有面下很多看不到的东西支撑着&#xff0c;因此可能只看到或学到别人的皮…
阅读更多...
深入解析Java内存模型：原理与并发优化实践

深入解析Java内存模型：原理与并发优化实践

深入解析Java内存模型&#xff1a;原理与并发优化实践 技术背景与应用场景 随着多核处理器的普及&#xff0c;Java并发编程已成为后端系统提升吞吐量与响应性能的必备手段。然而&#xff0c;在多线程环境下&#xff0c;不同线程对共享变量的可见性、指令重排以及内存屏障控制都…
阅读更多...
《设计模式之禅》笔记摘录 - 9.责任链模式

《设计模式之禅》笔记摘录 - 9.责任链模式

责任链模式的定义责任链模式定义如下&#xff1a;Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.…
阅读更多...
05-ES6

05-ES6

数据解构SetES6 提供了新的数据结构 Set。它类似于数组&#xff0c;但是成员的值都是唯一的&#xff0c;没有重复的值Set 本身是一个构造函数&#xff0c;用来生成 Set 数据结构//set集合&#xff0c;成员是唯一的,添加过程中会替换相同的元素。这里相同的标准是const s new S…
阅读更多...
正则表达式 \b：单词边界

正则表达式 \b：单词边界

下面举例说明 \b 用法。\b(?:https?://)(\S)\b各部分功能&#xff1a;\b&#xff1a;单词边界&#xff0c;确保匹配的 URL 是独立的单词&#xff0c;不会与其他字符粘连。(?:https?://)&#xff1a;非捕获组&#xff0c;匹配 http:// 或 https://&#xff08;s? 表示 s 可…
阅读更多...
从8h到40min的极致并行优化：Spark小数据集UDTF处理的深度实践与原理剖析

从8h到40min的极致并行优化：Spark小数据集UDTF处理的深度实践与原理剖析

在大数据领域&#xff0c;Spark以其卓越的并行处理能力著称。但面对小数据集的极致并行需求时&#xff0c;默认优化策略往往成为瓶颈。本文将深入剖析如何通过精准控制分区策略&#xff0c;将仅170条数据的表拆分成170个独立Task并行执行&#xff0c;实现100%的并行度&#xff…
阅读更多...
JAVA算法题练习day1

JAVA算法题练习day1

开始前&#xff1a; 选择leetcode-hot100。要求每日1道&#xff0c;并且需要亲自二刷昨天的题目&#xff08;每一种解法&#xff09;&#xff0c;要做解题笔记并发布CSDN&#xff0c;做完立刻二刷。做题时间为每日12&#xff1a;50起&#xff0c;不拖延&#xff0c;这是学习成…
阅读更多...
【Word Press进阶】自定义区块的行为与样式

【Word Press进阶】自定义区块的行为与样式

前两篇 【Word Press基础】创建自定义区块【Word Press基础】创建一个动态的自定义区块 说明白了怎么创建一个简单的静态区块。但实在是太丑了。这里再进行一个优化&#xff0c;让咱们的区块好看又好用。 一个合格的区块应当有着好看的外表&#xff0c;完整的功能&#xff0…
阅读更多...
Pygame模块化实战：火星救援游戏开发指南

Pygame模块化实战：火星救援游戏开发指南

Pygame模块化实战&#xff1a;火星救援游戏开发指南用Python打造太空探险游戏&#xff0c;掌握模块化开发核心技巧一、火星救援&#xff1a;模块化开发的完美场景​​想象这样的场景​​&#xff1a; 你是一名宇航员&#xff0c;被困在火星表面&#xff0c;需要收集资源、修复飞…
阅读更多...
三维图像识别中OpenCV、PCL和Open3D结合的主要技术概念、部分示例

三维图像识别中OpenCV、PCL和Open3D结合的主要技术概念、部分示例

文章目录1. 三维点云基础概念点云(Point Cloud)深度图像(Depth Image)体素(Voxel)2. 点云预处理技术去噪滤波(Noise Filtering)降采样(Downsampling)3. 特征提取与描述法向量估计(Normal Estimation)关键点检测(Keypoint Detection)特征描述子(Feature Descriptor)4. 点云配准(…
阅读更多...
7.23数据结构——单链表

7.23数据结构——单链表

文章目录一、思维导图二、单链表代码head.htext.cmain.c现象一、思维导图 二、单链表代码 head.h #ifndef __HEAD_H__ #define __HEAD_H__#include <stdlib.h> #include <stdio.h> #include <string.h>enum A {FAULSE-1,//失败返回SUCCESS//成功返回};//给…
阅读更多...
某种物联网SIM卡流量查询方法

某种物联网SIM卡流量查询方法

说起流量卡，很多人可能还停留在营业厅办理的常规套餐里。但其实在 2016 年，三大运营商就推出了一种资费更为划算的正规流量卡 —— 物联卡。当年，当不少人还在用 50 元 1G 的流量时，第一批体验物联卡的用户已经享受到了 53 元 6G 的全国流量，彻底摆脱了流量焦虑。不过，至…
阅读更多...
XTTS实现语音克隆：精确控制音频格式与生成流程【TTS的实战指南】

XTTS实现语音克隆：精确控制音频格式与生成流程【TTS的实战指南】

言简意赅的讲解XTTS解决的痛点 &#x1f4ce; 前置操作&#xff1a;如何使用 OBS Studio 录制高质量 WAV 语音&#xff08;建议先阅读并准备录音样本&#xff09; 本教程介绍如何使用 Coqui TTS 的 XTTS v2 模型 实现中文语音克隆&#xff0c;支持直接传入 .wav 文件&#xff0…
阅读更多...
C/C++中常量放置在比较操作符左侧

C/C++中常量放置在比较操作符左侧

目录 介绍 原因详解 避免误用赋值运算符 示例对比 结论 介绍 在编程中&#xff0c;将常量放在比较操作符&#xff08;如 或 !&#xff09;的左侧&#xff08;例如 if (42 value)&#xff09;&#xff0c;是一种被称为 "Yoda 条件"&#xff08;Yoda Conditions…
阅读更多...
Node.js 模拟 Linux 环境

Node.js 模拟 Linux 环境

&#x1f9e9; 项目介绍 该项目使用 Node.js 实现了一个模拟的 Linux 终端环境&#xff0c;支持多种常见的 Linux 命令&#xff08;如 ls, cd, cat, mkdir, rm 等&#xff09;&#xff0c;所有文件操作都在内存中进行&#xff0c;并持久化到本地文件系统中。适合用于学习 Shel…
阅读更多...
HAProxy 实验指南：从零开始搭建高可用负载均衡系统

HAProxy 实验指南：从零开始搭建高可用负载均衡系统

引言HAProxy&#xff08;High Availability Proxy&#xff09;是一款高性能的TCP/HTTP负载均衡器和代理服务器&#xff0c;广泛用于构建高可用、可扩展的Web架构。它由法国开发者Willy Tarreau于2000年开发&#xff0c;如今已成为开源社区和企业级应用中不可或缺的工具。HAProx…
阅读更多...
2.10DOM和BOM插入/移除/克隆

2.10DOM和BOM插入/移除/克隆

1.DOM创建/插入/移除/克隆1.1创建元素前面我们使用过 document.write 方法写入一个元素&#xff1a;这种方式写起来非常便捷&#xff0c;但是对于复杂的内容、元素关系拼接并不方便&#xff1b;它是在早期没有 DOM 的时候使用的方案&#xff0c;目前依然被保留了下来&#xff1…
阅读更多...
华为仓颉编程语言的表达式及其特点

华为仓颉编程语言的表达式及其特点

华为仓颉编程语言的表达式及其特点 仓颉&#xff08;Cangjie&#xff09;语言的表达式有一个明显的特点&#xff0c;范围不再局限于传统算术运算&#xff0c;而是扩展到条件表达式、循环表达式等多种类型&#xff0c;每种表达式均有确定的类型和值。 传统基本表达式&#xff0…
阅读更多...
最新文章

Copyright @ 2022~2023