崔安兵的博客

概述Docker 对 IPv6 的支持已经很久了，但默认仍未启用。本文记录在 Debian 13 下通过 NAT ULA，让容器获得 IPv6 出网能力。这种方式无需配置复杂的路由广播，使用体验与 IPv4 几乎完全一致。 内核前提：宿主机开启 IPv6 转发 sysctl net.ipv6.conf.all.forwarding=1。 修改配置编辑 Docker 守护进程配置文件 1sudo vim /etc/docker/daemon.json 写入以下配置： 123456789101112131415161718192021{ "log-driver": "json-file", "log-opts": { "max-size": "20m", "max-file": "3" }, "ipv6": true, "fixed-cidr-v6": &...

Lambda 架构一、理论概念Lambda 架构是由 Nathan Marz 提出的大数据混合架构，核心思想：同时使用批处理层 + 速度层（实时层），再通过服务层合并两套结果对外提供查询，用来解决：海量数据下，既要全量准确离线结果，又要低延迟实时视图。 背景：早期纯批处理延迟很高，只能 T+1；纯流处理早期很难做到完美容错、数据不丢不重。Lambda 折中：批层保证最终准确，速度层补上实时增量。 Lambda 四层结构简化版： flowchart LR Source[数据源] --> Batch[批处理层<br/>生成批视图] Source --> Speed[速度层<br/>生成实时视图] Batch --> Serving[服务层<br/>合并两套视图] Speed --> Serving Serving --> App[业务应用查询] 细化版本： flowchart TD A[数据源<br/>日志/传感器/业务事件] --> B[(原始数...

人们通常把系统架构设计师类比为建筑师，其共同点都是做好顶层设计，充当需求方和实施者的桥梁。但是系统架构设计师和建筑师存在许多不同，对于建筑师而言，在成为建筑设计师之前，是不会成为建筑工人或工程师的；而系统架构设计师一定是从工程师成长起来的。 工程师和架构设计师的本质区别主要体现在技术、组织和个人成长上。 在技术上，架构设计师的首要工作是抽象建模，而比首要工作更重要的是要了解自己所处的业务领域。只有对业务足够了解，才能更好地抽象和建模，也更能沉淀通用的设计方法论。另一方面，架构设计师需要了解甚至精通业务领域所涉及的技术领域，譬如对于互联网行业的架构设计师，小到语言、算法、数据库，大到网络协议、分布式系统、服务器、中间件、IDC等等都需要涉猎。一句话，架构设计师是技术团队的对外接口人，也应该是外部团队技术问题的终结者。除广度之外还要有深度，对于关键技术模块的设计，架构设计师需要有技术的权威性。而工程师则属于开发团队成员，主要负责项目的具体实现工作，在架构设计师的指导和帮助下，要熟悉相关业务流程，懂得建模方法，使用已确定的开发方法进行设计、编码和测试等工作，从掌握专用技术知识层面来讲...

在软件测试体系中，黑盒测试关注输入输出的业务结果，不关心内部代码逻辑；而白盒测试恰恰相反，它穿透功能表象，聚焦程序底层代码结构、执行逻辑、分支路径与数据流转，是保障代码质量、挖掘隐性逻辑Bug的核心手段。 很多团队只重视接口、功能黑盒测试，导致大量代码分支、边界逻辑、异常场景遗漏，上线后频发隐性故障。本文将全方位拆解白盒测试的所有核心方法，结合通俗案例、强弱对比、适用场景和落地最佳实践，帮你彻底吃透代码级测试。 一、白盒测试核心概述1. 什么是白盒测试？白盒测试又称结构测试、逻辑驱动测试、透明盒测试。测试人员完全知晓程序内部代码结构、执行流程、逻辑判断，基于代码实现逻辑设计测试用例，验证代码执行是否符合预期，而非单纯验证业务功能。 2. 核心测试目标 覆盖所有代码语句、分支、逻辑条件，避免代码冗余、死代码 发现逻辑漏洞、条件判断错误、路径执行异常 排查变量定义、数据流转、循环边界等隐性问题 保障代码健壮性，降低迭代回归故障风险 3. 适用场景主要用于单元测试、模块测试，重点覆盖核心算法、金额计算、权限校验、复杂分支逻辑、循环逻辑等高危代码模块，常与黑盒测试互补使用。 4. 通用...

接手过烂代码的人都有这种体验：加一个新需求，改一个文件，崩三个地方，回归测一周。代码是能跑，但没人敢改。而另一类代码，加需求只是”新增一个类”，旧的代码一行不动。两者之间差的，往往不是技术能力，而是七个设计原则。 写代码的第一天老师就教我们”高内聚、低耦合”，但真正落地的时候，靠的是这七个可执行的原则：单一职责、开放封闭、里氏替换、依赖倒置、接口隔离、组合复用、迪米特法则。它们不教你怎么实现功能，而是教你怎么让代码”扛得住变化”。 先给一张总览表，心里有个地图，后面逐个拆解。 原则 一句话本质 关注点 单一职责 SRP 一个类只有一个引起变化的原因 类级 开放封闭 OCP 对扩展开放、对修改关闭 类/模块级 里氏替换 LSP 子类必须能无缝替换父类且不破坏契约 继承关系 依赖倒置 DIP 高层不依赖低层，都依赖抽象 依赖方向 接口隔离 ISP 客户端不依赖它用不到的接口方法 接口粒度 组合复用 CRP 优先组合（has-a）而非继承（is-a） 复用方式 迪米特 LoD 只和直接朋友说话，不和陌生人通信 耦合面 一、单一职责...

摘要：结构化软件设计中，“高内聚、低耦合”是经久不衰的核心设计原则。很多开发者只记住这句口号，却分不清什么是内聚、不同内聚等级的差异，在真实项目中依然写出大而全、职责混乱的模块。本文从基础原理出发，讲解七种内聚等级，结合业务项目实例，说明如何识别低内聚问题，以及如何落地高内聚的模块设计。 在软件结构化设计方法论里，评价模块质量有两个核心标尺：内聚（Cohesion）衡量模块内部元素的紧密程度，耦合（Coupling）衡量模块与外部其他模块之间的依赖程度。我们常说的目标是高内聚，低耦合。 简单概括：高内聚，就是让一个模块内部所有代码，都围绕同一个目标、同一项职责工作；模块只做一件事，模块内部逻辑高度相关，无关逻辑绝不混入进来。 内聚不是一个布尔值“是或不是”，它分成七个明确等级，从差到好依次为：偶然内聚、逻辑内聚、时间内聚、过程内聚、通信内聚、顺序内聚、功能内聚。等级越低，维护成本越高；等级越高，模块越健壮，越容易阅读、修改、测试、复用。 一、七种内聚等级原理解析1. 偶然内聚（巧合内聚，最差）把一堆互相之间没有业务、数据、逻辑关联的代码，仅仅因为到处被调用，就强行塞到同一个模...

Vant官方文档 https://vant.pro/vant/#/zh-CN/home 🚀 性能极佳，组件平均体积小于 1KB（min+gzip）🚀 80+ 个高质量组件，覆盖移动端主流场景🚀 零外部依赖，不依赖三方 npm 包💪 使用 TypeScript 编写，提供完整的类型定义💪 单元测试覆盖率超过 90%，提供稳定性保障📖 提供丰富的中英文文档和组件示例📖 提供 Sketch 和 Axure 设计资源🍭 支持 Vue 2、Vue 3 和微信小程序🍭 支持主题定制，内置 700+ 个主题变量🍭 支持按需引入和 Tree Shaking🌍 支持国际化，内置 30+ 种语言包安装依赖 1234# Vue 3 项目，安装最新版 Vantnpm i vant# Vue 2 项目，安装 Vant 2npm i vant@latest-v2 组件注册全局注册123456789101112import { createApp } from 'vue'const app = createApp()// 1. 引入你需要的组...

管理学中有一个非常朴素却极度精准的规律：要求80分，最终往往只能做到60分；敢要求100分，大概率能稳稳拿到80分。这句经验总结，源自古训“取法于上，仅得为中；取法于中，故为其下”。在数字化项目落地、软件采购与服务商协作的场景中，这条定律几乎是铁律，精准解释了绝大多数软件项目“落地打折、效果不及预期”的核心原因。 很多企业与软件供应商合作时，总陷入自我妥协的误区：需求能凑合用就行、功能达标就可以、交付不延期就满意。看似降低了合作门槛、减少了沟通成本，实则从源头预留了效果折损的空间。软件项目不同于标准化实物采购，它存在天然的损耗：供应商的人力轮换、开发理解偏差、售后响应滞后、迭代优先级偏移、现场适配偏差，每一个环节都会让既定的交付标准悄悄降级。如果我们的目标和标准本身就是中等水平，经过层层损耗后，最终落地结果必然是下等水平。 低标准要求，是软件项目最大的隐患很多甲方对接供应商的常态，完美印证了“求其中，得其下”的短板。需求沟通时，只模糊提出“实现基础功能”，不明确性能指标、交互标准、容错机制和兼容要求；合同签订时，只约束交付周期和基础功能清单，不对响应速度、bug修复时效、迭代服务...

SpringBoot 提供了多种项目启动后自动执行初始化逻辑的方式，适用于不同场景（加载配置、初始化数据、预热缓存、启动定时任务等）。 1. 推荐首选：CommandLineRunner 接口（最简单）适用场景：简单的初始化逻辑，无依赖顺序要求。 特点：实现接口 + 重写 run 方法，SpringBoot 启动完成后自动调用。 12345678910111213141516171819202122232425262728293031import org.springframework.boot.CommandLineRunner;import org.springframework.stereotype.Component;/** * 项目启动后执行初始化 */@Componentpublic class MyInitRunner implements CommandLineRunner { /** * 启动完成后自动执行 * @param args 启动参数 * @throws Exception */ @Override...

在PG 数据库中表示”是/否”选择boolean还是char(1)还是int类型更为高效？在 PostgreSQL 中表示“是/否”选择，最高效且最推荐的方式是使用原生的 boolean 类型。 这主要是从存储空间、操作性能和语义清晰度三个维度来考量，boolean 类型在各方面都优于 char(1) 或 int。 📊 存储空间对比在存储空间上，boolean 的优势非常明显，并且能避免其他类型因数据对齐产生的额外开销。 数据类型 存储空间 说明 boolean 1 字节 最小，且无对齐填充开销。 char(1) 至少 2 字节 实际需要约5字节或更多，因为有类型开销和对齐填充。 int / smallint 4 字节 / 2 字节 int为4字节，smallint为2字节。两者都有对齐填充开销。 根据一份资料，存储100万行数据，boolean 类型仅需 1 MB，而 char(1) 和 smallint 都需要 2 MB。 ⚡️ 性能与语义对比除了存储空间，boolean 在性能和语义上也是最佳选择。 b...