【Go实现】实践GoF的23种设计模式:建造者模式

原创 元闰子的邀请 2022-05-05 22:33

上一篇:【Go实现】实践GoF的23种设计模式:单例模式

简单的分布式应用系统(示例代码工程):https://github.com/ruanrunxue/Practice-Design-Pattern--Go-Implementation

简述

在程序设计中,我们会经常遇到一些复杂的对象,其中有很多成员属性,甚至嵌套着多个复杂的对象。这种情况下,创建这个复杂对象就会变得很繁琐。对于 C++/Java 而言,最常见的表现就是构造函数有着长长的参数列表:

MyObject obj = new MyObject(param1, param2, param3, param4, param5, param6, ...)

对于 Go 语言来说,最常见的表现就是多层的嵌套实例化:

obj := &MyObject{
  Field1: &Field1 {
    Param1: &Param1 {
      Val: 0,
    },
    Param2: &Param2 {
      Val: 1,
    },
    ...
  },
  Field2: &Field2 {
    Param3: &Param3 {
      Val: 2,
    },
    ...
  },
  ...
}

上述的对象创建方法有两个明显的缺点:(1)对使用者不友好,使用者在创建对象时需要知道的细节太多;(2)代码可读性很差

针对这种对象成员较多,创建对象逻辑较为繁琐的场景,非常适合使用建造者模式来进行优化。

建造者模式的作用有如下几个:

1、封装复杂对象的创建过程,使对象使用者不感知复杂的创建逻辑。
2、可以一步步按照顺序对成员进行赋值,或者创建嵌套对象,并最终完成目标对象的创建。
3、对多个对象复用同样的对象创建逻辑。
其中,第1和第2点比较常用,下面对建造者模式的实现也主要是针对这两点进行示例。

UML 结构

代码实现

示例

在简单的分布式应用系统(示例代码工程)中,我们定义了服务注册中心,提供服务注册、去注册、更新、 发现等功能。要实现这些功能,服务注册中心就必须保存服务的信息,我们把这些信息放在了 ServiceProfile 这个数据结构上,定义如下:

// demo/service/registry/model/service_profile.go
// ServiceProfile 服务档案,其中服务ID唯一标识一个服务实例,一种服务类型可以有多个服务实例
type ServiceProfile struct {
    Id       string           // 服务ID
    Type     ServiceType      // 服务类型
    Status   ServiceStatus    // 服务状态
    Endpoint network.Endpoint // 服务Endpoint
    Region   *Region          // 服务所属region
    Priority int              // 服务优先级,范围0~100,值越低,优先级越高
    Load     int              // 服务负载,负载越高表示服务处理的业务压力越大
}

// demo/service/registry/model/region.go
// Region 值对象,每个服务都唯一属于一个Region
type Region struct {
 Id      string
 Name    string
 Country string
}

// demo/network/endpoint.go
// Endpoint 值对象,其中ip和port属性为不可变,如果需要变更,需要整对象替换
type Endpoint struct {
 ip   string
 port int
}

实现

如果按照直接实例化方式应该是这样的:

// 多层的嵌套实例化
profile := &ServiceProfile{
 Id:       "service1",
 Type:     "order",
 Status:   Normal,
 Endpoint: network.EndpointOf("192.168.0.1"8080),
 Region: &Region{ // 需要知道对象的实现细节
  Id:      "region1",
  Name:    "beijing",
  Country: "China",
 },
 Priority: 1,
 Load:     100,
}

虽然 ServiceProfile 结构体嵌套的层次不多,但是从上述直接实例化的代码来看,确实存在对使用者不友好代码可读性较差的缺点。比如,使用者必须先对 Endpoint 和 Region 进行实例化,这实际上是将 ServiceProfile 的实现细节暴露给使用者了。
下面我们引入建造者模式对代码进行优化重构:

// demo/service/registry/model/service_profile.go
// 关键点1: 为ServiceProfile定义一个Builder对象
type serviceProfileBuild struct {
    // 关键点2: 将ServiceProfile作为Builder的成员属性
 profile *ServiceProfile
}

// 关键点3: 定义构建ServiceProfile的方法
func (s *serviceProfileBuild) WithId(id string) *serviceProfileBuild {
 s.profile.Id = id
    // 关键点4: 返回Builder接收者指针,支持链式调用
 return s
}

func (s *serviceProfileBuild) WithType(serviceType ServiceType) *serviceProfileBuild {
 s.profile.Type = serviceType
 return s
}

func (s *serviceProfileBuild) WithStatus(status ServiceStatus) *serviceProfileBuild {
 s.profile.Status = status
 return s
}

func (s *serviceProfileBuild) WithEndpoint(ip string, port int) *serviceProfileBuild {
 s.profile.Endpoint = network.EndpointOf(ip, port)
 return s
}

func (s *serviceProfileBuild) WithRegion(regionId, regionName, regionCountry) *serviceProfileBuild {
    s.profile.Region = &Region{Id: regionId, Name: regionName, Country: regionCountry}
 return s
}

func (s *serviceProfileBuild) WithPriority(priority int) *serviceProfileBuild {
 s.profile.Priority = priority
 return s
}

func (s *serviceProfileBuild) WithLoad(load int) *serviceProfileBuild {
 s.profile.Load = load
 return s
}

// 关键点5: 定义Build方法,在链式调用的最后调用,返回构建好的ServiceProfile
func (s *serviceProfileBuild) Build() *ServiceProfile {
 return s.profile
}

// 关键点6: 定义一个实例化Builder对象的工厂方法
func NewServiceProfileBuilder() *serviceProfileBuild {
 return &serviceProfileBuild{profile: &ServiceProfile{}}
}

实现建造者模式有 6 个关键点:

  1. 为 ServiceProfile 定义一个 Builder 对象 serviceProfileBuild,通常我们将它设计为包内可见,来限制客户端的滥用。
  2. 把需要构建的 ServiceProfile 作为 Builder 对象 serviceProfileBuild 的成员属性,用来存储构建过程中的状态。
  3. 为 Builder 对象 serviceProfileBuild 定义用来构建 ServiceProfile 的一系列方法,上述代码中我们使用了 WithXXX 的风格。
  4. 在构建方法中返回 Builder 对象指针本身,也即接收者指针,用来支持链式调用,提升客户端代码的简洁性。
  5. 为 Builder 对象定义 Build() 方法,返回构建好的 ServiceProfile 实例,在链式调用的最后调用。
  6. 定义一个实例化 Builder 对象的工厂方法 NewServiceProfileBuilder()

那么,使用建造者模式实例化逻辑是这样的:

// 建造者模式的实例化方法
profile := NewServiceProfileBuilder().
                WithId("service1").
                WithType("order").
                WithStatus(Normal).
                WithEndpoint("192.168.0.1"8080).
                WithRegion("region1""beijing""China").
                WithPriority(1).
                WithLoad(100).
                Build()

当使用建造者模式来进行对象创建时,使用者不再需要知道对象具体的实现细节(这里体现为无须预先实例化 Endpoint 和 Region 对象),代码可读性、简洁性也更好了。

扩展

Functional Options 模式

进一步思考,其实前文提到的建造者实现方式,还有 2 个待改进点:

  1. 我们额外新增了一个 Builder 对象,如果能够把 Builder 对象省略掉,同时又能避免长长的入参列表就更好了。
  2. 熟悉 Java 的同学应该能够感觉出来,这种实现具有很强的“Java 风格”。并非说这种风格不好,而是在 Go 中理应有更具“Go 风格”的建造者模式实现。

针对这两点,我们可以通过 Functional Options 模式 来优化。Functional Options 模式也是用来构建对象的,这里我们也把它看成是建造者模式的一种扩展。它利用了 Go 语言中函数作为一等公民的特点,结合函数的可变参数,达到了优化上述 2 个改进点的目的。
使用 Functional Options 模式的实现是这样的:

// demo/service/registry/model/service_profile_functional_options.go
// 关键点1: 定义构建ServiceProfile的functional option,以*ServiceProfile作为入参的函数
type ServiceProfileOption func(profile *ServiceProfile)

// 关键点2: 定义实例化ServiceProfile的工厂方法,使用ServiceProfileOption作为可变入参
func NewServiceProfile(svcId string, svcType ServiceType, options ...ServiceProfileOption) *ServiceProfile {
    
// 关键3: 可为特定的字段提供默认值
 profile := &ServiceProfile{
  Id:       svcId,
  Type:     svcType,
  Status:   Normal,
  Endpoint: network.EndpointOf(
"192.168.0.1"80),
  Region:   &Region{Id: 
"region1", Name: "beijing", Country: "China"},
  Priority: 
1,
  Load:     
100,
 }
    
// 关键点4: 通过ServiceProfileOption来修改字段
 
for _, option := range options {
  option(profile)
 }
 
return profile
}

// 关键点5: 定义一系列构建ServiceProfile的方法,在ServiceProfileOption实现构建逻辑,并返回ServiceProfileOption
func Status(status ServiceStatus) ServiceProfileOption {
 
return func(profile *ServiceProfile) {
  profile.Status = status
 }
}

func Endpoint(ip string, port int) ServiceProfileOption {
 
return func(profile *ServiceProfile) {
  profile.Endpoint = network.EndpointOf(ip, port)
 }
}

func SvcRegion(svcId, svcName, svcCountry string) ServiceProfileOption {
 
return func(profile *ServiceProfile) {
  profile.Region = &Region{
   Id:      svcId,
   Name:    svcName,
   Country: svcCountry,
  }
 }
}

func Priority(priority int) ServiceProfileOption {
 
return func(profile *ServiceProfile) {
  profile.Priority = priority
 }
}

func Load(load int) ServiceProfileOption {
 
return func(profile *ServiceProfile) {
  profile.Load = load
 }
}

实现 Functional Options 模式有 5 个关键点:

  1. 定义 Functional Option 类型 ServiceProfileOption,本质上是一个入参为构建对象 ServiceProfile 的指针类型。(注意必须是指针类型,值类型无法达到修改目的)
  2. 定义构建 ServiceProfile 的工厂方法,以 ServiceProfileOption 的可变参数作为入参。函数的可变参数就意味着可以不传参,因此一些必须赋值的属性建议还是定义对应的函数入参。
  3. 可为特定的属性提供默认值,这种做法在 为配置对象赋值的场景 比较常见。
  4. 在工厂方法中,通过 for 循环利用 ServiceProfileOption 完成构建对象的赋值。
  5. 定义一系列的构建方法,以需要构建的属性作为入参,返回 ServiceProfileOption 对象,并在ServiceProfileOption 中实现属性赋值。

Functional Options 模式 的实例化逻辑是这样的:

// Functional Options 模式的实例化逻辑
profile := NewServiceProfile("service1""order",
 Status(Normal),
 Endpoint("192.168.0.1"8080),
 SvcRegion("region1""beijing""China"),
 Priority(1),
 Load(100))

相比于传统的建造者模式,Functional Options 模式的使用方式明显更加的简洁,也更具“Go 风格”了。

Fluent API 模式

前文中,不管是传统的建造者模式,还是 Functional Options 模式,我们都没有限定属性的构建顺序,比如:

// 传统建造者模式不限定属性的构建顺序
profile := NewServiceProfileBuilder().
                WithPriority(1).  // 先构建Priority也完全没问题
                WithId("service1").
                ...
// Functional Options 模式也不限定属性的构建顺序
profile := NewServiceProfile("service1""order",
    Priority(1),  // 先构建Priority也完全没问题
 Status(Normal),
    ...

但是在一些特定的场景,对象的属性是要求有一定的构建顺序的,如果违反了顺序,可能会导致一些隐藏的错误。
当然,我们可以与使用者的约定好属性构建的顺序,但这种约定是不可靠的,你很难保证使用者会一直遵守该约定。所以,更好的方法应该是通过接口的设计来解决问题, Fluent API 模式 诞生了。
下面,我们使用 Fluent API 模式进行实现:

// demo/service/registry/model/service_profile_fluent_api.go
type (
    // 关键点1: 为ServiceProfile定义一个Builder对象
 fluentServiceProfileBuilder struct {
        // 关键点2: 将ServiceProfile作为Builder的成员属性
  profile *ServiceProfile
 }
    // 关键点3: 定义一系列构建属性的fluent接口,通过方法的返回值控制属性的构建顺序
 idBuilder interface {
  WithId(id string) typeBuilder
 }
 typeBuilder interface {
  WithType(svcType ServiceType) statusBuilder
 }
 statusBuilder interface {
  WithStatus(status ServiceStatus) endpointBuilder
 }
 endpointBuilder interface {
  WithEndpoint(ip string, port int) regionBuilder
 }
 regionBuilder interface {
  WithRegion(regionId, regionName, regionCountry string) priorityBuilder
 }
 priorityBuilder interface {
  WithPriority(priority int) loadBuilder
 }
 loadBuilder interface {
  WithLoad(load int) endBuilder
 }
 // 关键点4: 定义一个fluent接口返回完成构建的ServiceProfile,在最后调用链的最后调用
 endBuilder interface {
  Build() *ServiceProfile
 }
)

// 关键点5: 为Builder定义一系列构建方法,也即实现关键点3中定义的Fluent接口
func (f *fluentServiceProfileBuilder) WithId(id string) typeBuilder {
 f.profile.Id = id
 return f
}

func (f *fluentServiceProfileBuilder) WithType(svcType ServiceType) statusBuilder {
 f.profile.Type = svcType
 return f
}

func (f *fluentServiceProfileBuilder) WithStatus(status ServiceStatus) endpointBuilder {
 f.profile.Status = status
 return f
}

func (f *fluentServiceProfileBuilder) WithEndpoint(ip string, port int) regionBuilder {
 f.profile.Endpoint = network.EndpointOf(ip, port)
 return f
}

func (f *fluentServiceProfileBuilder) WithRegion(regionId, regionName, regionCountry string) priorityBuilder {
 f.profile.Region = &Region{
  Id:      regionId,
  Name:    regionName,
  Country: regionCountry,
 }
 return f
}

func (f *fluentServiceProfileBuilder) WithPriority(priority int) loadBuilder {
 f.profile.Priority = priority
 return f
}

func (f *fluentServiceProfileBuilder) WithLoad(load int) endBuilder {
 f.profile.Load = load
 return f
}

func (f *fluentServiceProfileBuilder) Build() *ServiceProfile {
 return f.profile
}

// 关键点6: 定义一个实例化Builder对象的工厂方法
func NewFluentServiceProfileBuilder() idBuilder {
 return &fluentServiceProfileBuilder{profile: &ServiceProfile{}}
}

实现 Fluent API 模式有 6 个关键点,大部分与传统的建造者模式类似:

  1. 为 ServiceProfile 定义一个 Builder 对象 fluentServiceProfileBuilder
  2. 把需要构建的 ServiceProfile 设计为 Builder 对象 fluentServiceProfileBuilder 的成员属性。
  3. 定义一系列构建属性的 Fluent 接口,通过方法的返回值控制属性的构建顺序,这是实现 Fluent API 的关键。比如 WithId 方法的返回值是 typeBuilder 类型,表示紧随其后的就是 WithType 方法。
  4. 定义一个 Fluent 接口(这里是 endBuilder)返回完成构建的 ServiceProfile,在最后调用链的最后调用。
  5. 为 Builder 定义一系列构建方法,也即实现关键点 3 中定义的 Fluent 接口,并在构建方法中返回 Builder 对象指针本身。
  6. 定义一个实例化 Builder 对象的工厂方法 NewFluentServiceProfileBuilder(),返回第一个 Fluent 接口,这里是 idBuilder,表示首先构建的是 Id 属性。

Fluent API 的使用与传统的建造者实现使用类似,但是它限定了方法调用的顺序。如果顺序不对,在编译期就报错了,这样就能提前把问题暴露在编译器,减少了不必要的错误使用。

// Fluent API的使用方法
profile := NewFluentServiceProfileBuilder().
 WithId("service1").
 WithType("order").
 WithStatus(Normal).
 WithEndpoint("192.168.0.1"8080).
 WithRegion("region1""beijing""China").
 WithPriority(1).
 WithLoad(100).
 Build()

// 如果方法调用不按照预定的顺序,编译器就会报错
profile := NewFluentServiceProfileBuilder().
 WithType("order").
 WithId("service1").
 WithStatus(Normal).
 WithEndpoint("192.168.0.1"8080).
 WithRegion("region1""beijing""China").
 WithPriority(1).
 WithLoad(100).
 Build()
// 上述代码片段把WithType和WithId的调用顺序调换了,编译器会报如下错误
// NewFluentServiceProfileBuilder().WithType undefined (type idBuilder has no field or method WithType)

典型应用场景

建造者模式主要应用在实例化复杂对象的场景,常见的有:

  • 配置对象。比如创建 HTTP Server 时需要多个配置项,这种场景通过 Functional Options 模式就能够很优雅地实现配置功能。
  • SQL 语句对象。一些 ORM 框架在构造 SQL 语句时也经常会用到 Builder 模式。比如 xorm 框架中构建一个 SQL 对象是这样的:builder.Insert().Into("table1").Select().From("table2").ToBoundSQL()
  • 复杂的 DTO 对象
  • ......

优缺点

优点

1、将复杂的构建逻辑从业务逻辑中分离出来,遵循了单一职责原则
2、可以将复杂对象的构建过程拆分成多个步骤,提升了代码的可读性,并且可以控制属性构建的顺序。
3、对于有多种构建方式的场景,可以将 Builder 设计为一个接口来提升可扩展性
4、Go 语言中,利用 Functional Options 模式可以更为简洁优雅地完成复杂对象的构建。

缺点

1、传统的建造者模式需要新增一个 Builder 对象来完成对象的构造,Fluent API 模式下甚至还要额外增加多个 Fluent 接口,一定程度上让代码更加复杂了。

与其他模式的关联

抽象工厂模式和建造者模式类似,两者都是用来构建复杂的对象,但前者的侧重点是构建对象/产品族,后者的侧重点是对象的分步构建过程

参考

[1] 【Go实现】实践GoF的23种设计模式:SOLID原则, 元闰子

[2] Design Patterns, Chapter 3. Creational Patterns, GoF

[3] GO 编程模式:FUNCTIONAL OPTIONS, 酷壳 CoolShell

[4] Fluent API: Practice and Theory, Ori Roth

[5] XORM BUILDER, xorm

[6] 生成器模式, refactoringguru.cn

更多文章请关注微信公众号:元闰子的邀请


评论
  • 在物联网从“万物互联”迈向“万物智联”的进程中,LTE Cat.1凭借其在速率、成本与网络覆盖之间的完美平衡,正成为中低速物联网市场的绝对主力。随着2G/3G网络的逐步退网以及新国标对终端设备智能化、定位功能的强制要求,Cat.1模组迎来了爆发式的增长窗口。在这一关键节点,基于华为海思Hi2131芯片设计的LTE Cat.1模组,凭借其在能效、射频、架构及物理规格上的底层创新,成功打破了“高性能必高功耗”的传统魔咒,为行业提供了极具竞争力的连接最优解。核心技术优势:重塑Cat.1能效与连接标杆海
    用户1778981989717 2026-08-05 21:04 169浏览
  • 摘要在防爆电气设计中,只参照芯数选型而忽略额定载流量,长期满负荷运行会出现插头发热、接触面氧化、IP67 密封受热老化等问题。结合常用 3 针 3 孔、4 芯、5PIN、8PIN 圆形防爆连接器,制作分级电流参数对照表,区分冷压免焊接、焊接两种接线结构的安全载流数值,设置合理电流冗余系数,搭配使用环境修正参数,规范防爆接近开关连接器、防爆法兰插座的选型计算方式。关键词圆形防爆连接器,载流参数表,防爆法兰插座,防爆端子接头,IP67 防爆防水接插件1 产品概述圆形防爆连接器触点载流能力由插针直径、
    kyfbest科迎法电气 2026-08-03 09:18 128641浏览
  • ​摘要:低价大流量卡正全面退市,政策收紧已成定局。面对传统号卡的不确定性,随身WiFi凭借稳定连接、多设备共享、独立设备和灵活套餐等优势,成为务实可靠的备选方案。1、流量卡黄金时代要结束了通信行业正迎来一场前所未有的“地震式”调整——曾让无数用户追捧的低价大流量卡,正在全速退出各大平台。这早已不是一次普通的竞合,而是一场趋势性的行业洗牌。回望过去,19元200G的神卡,那时真是“睡着都能笑醒”,便宜到不敢相信,爽到忍不住炫耀。那些日子,好像随便刷、随便看,流量自由触手可及。可如今,回头再看,那种
    爱上电路设计 2026-08-03 10:21 128869浏览
  • 摘要防爆自控系统同时布设本安信号、工业总线、动力供电三类线路,仅依靠标识标牌管控插接极易出现人为错插问题,高压动力回路窜入本安弱电回路会突破安全栅限能标准,产生点火风险。依托 A、D、K 标准化机械防呆编码体系,搭配护套颜色区分管理,适配 3 针 3 孔免焊接冷压增安型防爆航插、5PIN 总线防爆航空插头、8 芯焊接防爆法兰插座的选型使用,从物理结构层面杜绝防爆接近开关连接器、防爆传感器航插接头混用插接问题,补齐防爆系统被动安全防护体系。关键词圆形防爆连接器,防呆编码防爆航插,防爆航空插头,防爆
    kyfbest科迎法电气 2026-07-31 18:29 407浏览
  • 文:杜杰编辑:侯煜当地时间7月28日,美国特朗普政府落地最新科技封锁政策,美国联邦通信委员会(FCC)正式更新《受管制清单》,新增两大类设备——境外生产的先进机器人设备、境外生产的联网电力逆变器。FCC在官方情况说明书中明确,该类境外制造产品,“会对美国国家安全或美国民众的人身安全构成无法承受的风险”。本次新规设置明确豁免机制:经美国国防部(DoW)、电力逆变器品类经美国国土安全部(DHS)审核并授予“有条件批准”,认定对应设备品类不存在重大安全风险,即可获得准入豁免。同时政策严格执行新老划断原
    华尔街科技眼 2026-08-03 21:28 325浏览
  • 在EMC测试过程中,传导发射(Conducted Emission,CE)超标是工程师最常遇到的问题之一。更令人头疼的是,同样的超标曲线背后,可能对应着完全不同的干扰机理:有的是差模噪声沿电源回路传播,有的是共模电流通过寄生路径耦合,还有些问题甚至并非来自电源本身,而是负载、电缆布局或接地结构引起的连锁反应。 · 150kHz~1MHz 超标:多为差模噪声为主,干扰沿火线-零线回路传输。 · 1MHz~30MHz 超标:通常共模噪声占主导,干扰通过火线/零线对地回路传播。 如果条件允许,用电流探
    誉磁电磁兼容EMC 2026-07-31 18:45 501浏览
  • 在前六期中,我们已经分别讨论了 CRA 的适用范围、整体影响、漏洞通报义务、风险评估与技术文档证据链、第三方组件与 SBOM 供应链治理,以及产品上市后的支持期、安全更新、用户说明和终止支持管理。到这里,企业已经能够回答几个核心问题:产品是否落入 CRA 适用范围,产品由哪些组件构成,企业如何证明自己在设计、开发和上市前采取了必要的安全措施,以及产品上市后如何持续维护和安全下线。但对于真正准备落地 CRA 合规的企业来说,还有一个更现实的问题:CRA 的法规条文相对原则化,企业应当如何把“网络安
    虹科云科技 2026-08-03 16:51 148758浏览
  • 导语在现代高速数字电路设计中,信号的完整性已不仅是理想波形推演,而是一场与物理非理想特性正面博弈的工程实践。滤波器芯片作为净化传输链路的关键屏障,其核心挑战在于:能否有效识别并滤除那些隐匿在电平跳变过程中的亚纳秒级瞬态脉冲干扰,这类干扰持续极短,却足以在高速链路中引发误触发。然而,传统函数发生器受限于采样率与边沿速率,根本无法忠实复现如此狭窄且陡峭的异常波形。针对此困境,德思特TS-AWG7000系列任意波形发生器以17 GS/s采样率与50 ps原生边沿速度,为瞬态脉冲提供精细刻画,配合SPG
    德思特测试测量 2026-08-05 14:06 5浏览
  • 做蓝牙音箱的工程师大概都碰过这个局面。产品要连手机放歌,要本地播开机提示音和按键音,还要接 App 做配网和状态上报。三件事拆开,早先的常规做法是音频蓝牙一颗料、数传蓝牙一颗料、本地播放再挂一颗小 MCU 加一片 Flash。板子越画越大,BOM 越算越贵,待机电流和固件工作量也跟着涨。WT2605C 出来以后,这套需求可以集成到一颗芯片,就是 WT2605C-32N,该芯片采用QFN32 封装,4×4 毫米,把音频蓝牙、BLE 数传和 MP3 本地播放三样全包了。对蓝牙音箱来说,最实在的好处就
    唯创知音语音芯片 2026-08-06 15:14 284浏览
  • 产品使用18V供电,配套4串锂离子电池,需要设计一个充电器。因为输入18V,电池最高 16.8V,压差仅 1.2V。因为压差太小。使用开关型的充电控制芯片不稳定。尝试自行设计一个。整体采用分立三极管 + TL431架构,分4个功能单元:使能控制回路、限流环路、TL431 精密恒压反馈环路、PNP 功率管主功率输出回路;实现完整锂电池充电逻辑。使能控制回路按键按下:5V 电压经 R12 (2kΩ) 送入 NPN 管 Q3 基极,Q3 饱和导通,对地拉低 R1、R2 组成的分压控制节点电位;该节点直
    southcreek 2026-08-07 13:45 316浏览
  •        很多人只见过封装在SMD外壳里的小尺寸晶振,却不知道一颗2016、1612甚至1210封装的微型石英晶振,从一块巴掌大的石英原矿,到最终能稳定起振的成品,要经过十几道精密工序。它内部的石英晶片厚度最薄不到20微米,比普通A4纸的1/5还薄,整个生产过程里哪怕0.1微米的误差,都会直接废掉整批产品,这也是小尺寸晶振过去长期依赖进口,国内厂商花了十几年才啃下量产硬骨头的核心原因。1. 原石定向切割:0.01度的角度误差都不能有小尺寸晶振的第一步,
    TKD泰晶科技 2026-08-07 08:43 374浏览
  •                                                                        
    广州铁金刚 2026-08-06 17:44 99876浏览
我要评论
0
点击右上角,分享到朋友圈 我知道啦
请使用浏览器分享功能 我知道啦