发动态
图文
列表
置顶
【元器件规范共建召集令】诚邀行业专家,定义行业规范新基准
当你在电子元器件选型时,是否因参数定义模糊反复试错?当你推进研发项目时,是否因标准不统一延误进度?如今,有一个能改变行业现状、为电子产业发展注入新动能的机会 —— 加入立创商城电子元器件规范共建项目,与更多行业专家携手,打造科学、完善、权威的元器件参数规范体系!立创商城深耕电子元器件电商领域多年,深知统一精准的参数规范对行业上下游的重要性。我们正启动一项开创性工程,现面向全国电子元器件行业规范制定人、电子行业从业者、电子专业教育从业者、资深领域电子爱好者等群体招募 20-50 名细分领域专家,涵盖接口芯片、时钟和定时、射频无线、传感器等 9 大核心方向,邀你成为这场 “规范革命” 的 “执笔人”。1、你将参与的核心领域(涵盖9大方向)接口芯片USB、PCIe、CAN芯片等接口芯片的设计关注核心参数范围划定及其参数名词解释时钟和定时晶振、定时器、时钟发生器等震荡器的设计关注核心参数范围划定及其参数名词解释射频无线RF芯片、天线模块、无线收发器等无线射频相关器件的的设计关注核心参数范围划定及其参数名词解释传感器温度、压力、光电等传感器的设计关注核心参数范围划定及其参数名词解释功能模块电源管理、信号调理模块等电子模块的设计关注核心参数范围划定及其参数名词解释物联网/通信模块5G、WiFi、蓝牙模块等无线通讯模块的设计关注核心参数范围划定及其参数名词解释单片机/微控制器ST、TI、STC等单片机器件的设计关注核心参数范围划定及其参数名词解释逻辑器件和数据转换ADC/DAC、逻辑门等与信号转换和数据转换相关的设计关注核心参数范围划定及其参数名词解释显示屏器件OLED、LCD等显示屏的设计关注核心参数范围划定及其参数名词解释 2、你的角色:从技术实践者到标准制定者评审与优化:针对公司内部团队起草的规范初稿(如参数定义、填写规范、案例模板),以专业视角审核逻辑严谨性,提出修改建议(例如隔离电压、CMTI等参数的单位换算、优先级规则);深度参与:基于实操经验,为芯片引脚定义、数据速率计算、温度范围界定等参数提供行业实践案例,确保规范兼具理论准确性与工程可行性;成果共创:与跨领域专家协作,构建类似“电子元器件维基百科”的公开规范网站,让技术标准真正服务行业生态。3、我们为你提供的四大价值回报「行业署名权」:每一份经你评审修改的规范,均将在最终版本中明确标注你的姓名与单位,成为个人技术生涯的权威背书;「品牌曝光度」:规范公开时,参与评审与编撰的专家名单将同步公示,通过公司官方渠道(行业媒体、技术社区)定向推送,提升行业影响力;「知识共享平台」:加入电子元器件规范维基网站建设,你的技术见解将被全球工程师查阅引用,成为领域内的“隐形标准制定者”;「多样激励体系」:任务制,每次任务均有丰厚报酬奖励,根据审核规范复杂度与贡献度可获取,包括且不限于京东E卡/采购晶/优惠券/实物奖励等,多劳多得激励形式:1、积分制每次任务,每人均可获得积分,根据每人贡献程度获得对应积分贡献程度人数获得积分皇冠125黄金315白银610青铜105 2、积分可兑换礼品积分数兑换礼品价值550E卡或50采购晶50元10100元E卡或100元采购晶100元20200元E卡或200元采购晶200元50500元E卡或500元采购晶500元1001000元E卡或1000元采购晶1000元2002000元E卡或2000元采购晶2000元 4、为什么工程师值得加入?技术价值升华:从“用标准”到“定标准”,让你的经验成为行业参照坐标; 资源链接机遇:与芯片原厂、方案商专家深度交流,拓展技术人脉圈; 职业发展加分:参与行业级规范制定的经历,是技术管理岗晋升的硬核背书。5、报名方式如果您在上述领域拥有多年以上研发/设计经验,或主导过元器件选型与参数验证项目,欢迎将个人简历(附技术专长说明)发送至:,邮件主题注明“【规范专家报名】+领域方向”。我们将在3个工作日内与您联系,共商规范共建蓝图。 电子元器件的每一个参数,都承载着工程师的智慧。现在,你就有机会成为定义行业规范的 “少数派”,让全球工程师使用你参与制定的标准。这不仅是一次技术实践,更是一段能为行业留下深刻印记、为职业增添高光的宝贵经历。立创商城期待与你携手,重塑元器件参数规范行业标杆,让你的技术印记,刻进行业未来! 注:“本次共建采用灵活协作模式,单次任务预计耗时2~4小时,全程线上进行,不影响日常工作。”
【元器件规范共建召集令】诚邀行业专家,定义行业规范新基准
立创商城
前言如果你点的椰果奶茶被做成了珍珠奶茶,虽然也能喝,但就是完全不是你想要的,至少对于我这种有点强迫症的人。那么 JavaScript 就是这样一个 “随性” 的奶茶店老板,而 TypeScript 就是那个拿着订单反复跟你确认 “少糖少冰” 的靠谱店员,从根源上避免了 “错单” 的尴尬。用一句话来说其实就是:TypeScript 是更严谨的 JavaScript。一、有了 JavaScript 为什么还要有 TypeScript ?写 JavaScript 就像开盲盒,你永远不知道下一个变量里装的是 数字、字符串还是 薛定谔的 undefined。我统称它们为 盲盒变量。比如这段代码:let n = 1, m = 0; n = 'hello'; // 数字秒变字符串,JS 主打一个“灵活” function add(a, b) { if (typeof a === 'number' && typeof b === 'number') { return a + b; } } // 传入字符串,函数直接返回 undefined,Bug 这不就来了 console.log(add(1, '2')); 你以为你在写 “动态灵活” 的代码,其实是在给未来的自己 埋雷。比如上面这段代码,可能你知道等会要传 2个number类型,但是如果别人直接拿来Ctrl + cv 用你封装的函数,传了一个 string类型 那就坏了。直到 TypeScript 出现,让变量从 “盲盒” 变成了 “明码标价的商品”。二、弱类型:自由过了火就是混乱在上面代码中有这样一个情况:let n = 1; n = 'hello'; // 在 JavaScript里面不报错 如果你是 C++、Java或者Go的工程师,你肯定会觉得这人怕不是敲代码敲疯了吧。在C++、Java或者Golang里面这代码直接就报错了。这就是因为 JavaScript 是典型的弱类型语言,变量不需要提前声明类型,随时可以 “变身”。打印结果为 hello:你可以让数字 a 一秒变成字符串,编辑器连个警告都没有。这种 “自由” 在小项目里或许能跑,但项目一复杂,就会出现 add(1, '2') 这种隐蔽 Bug,排查起来堪比大海捞针。三、强类型:给变量上 “户口”TypeScript 作为 JavaScript 的超集,核心就是给变量加上了类型声明。首先要用 TypeScript,我们需要去下载它:npm install -g typescript # 全局安装 TypeScript tsc -v # 查看 TypeScript的版本 tsc project.ts # project 是你的文件名,编译 TypeScript文件 当编译完你会发现编译器给你编译出了一份对等的JavaScript文件:这个时候你就可以用Node.js去跑这份文件,因为 TypeScript 本身不能直接运行,需要先编译成 JavaScript 再运行。不过现在有一些工具可以简化这个过程,比如 ts-node、deno 等。我这里简要介绍下 ts-node的使用:ls package.json # 首先检查项目是否有 package.json 文件 npm init -y # 如果没有,初始化一个 npm install -g ts-node # 然后安装 ts-node npm install --save-dev ts-node # 或本地安装 # 运行 TypeScript文件 ts-node 2.ts # 全局安装时 npx ts-node 2.ts # 本地安装时 一般 TypeScript 都是在 React项目 等环境下运行,所以直接运行一个文件的比较少见,这里我们主要看 TypeScript 语法的使用和基础知识。同样的代码,在 TypeScript 里面就会报错:let a: number = 1; a = 'hello'; // 编辑器直接标红:不能将类型 “string” 分配给类型 “number” console.log(a); 细心的你很快就发现了猫腻:TypeScript 相较于 JavaScript 不同的地方就在于 TypeScript 的写法中明确标注了变量是什么类型。就比如这里 a 被明确声明为 number 类型,如果你想把它改成字符串,TypeScript 会立刻报错,把问题扼杀在编码阶段。这样就使得文件更加严谨。<<<顺便说句,技术大厂,前后端-测试机会,一线双一线城市坑位充足,感兴趣可以看看这个~四、TypeScript 数据类型全家桶在之前我写过几篇 JavaScript数据类型 的文章,那我们现在来看看 TypeScript 类型全家桶,他们并不完全一样,但还是有很高的相似度。比如这段代码:let isDone: boolean = false; // boolean类型 let count: number = 123; // number类型 let str: string = 'Trae'; // string类型 const symbol: symbol = Symbol(); // symbol类型 let obj: object = { [symbol]: 'Trae' // object类型(对象) }; let list: number[] = [1, 2, 3]; // array类型(数组) enum Color { Red, Green, // 类似于结构体 Blue } let color: Color = Color.Red; let notSure: any = 10; // any类型 notSure = '123'; // any 类型可以随便变,是 TypeScript 里的 “漏网之鱼” let value: unknown = 10; // unknown类型 value = '123'; let abc: string = 'hello'; // unknown 类型不能直接赋值给其他类型,比 any 更安全 // abc = value; // 报错 abc = notSure; // 不报错 let tuple: [number, string] = [10, 'hello']; // 元组:固定长度和类型的数组 function user1(): number { return 123; } function user2(): Function { return function fn(): number { return 123; } } // 报错 // function user2(): string { // return 123; // } function user3(): void {} // void 表示没有返回值 let u: undefined = undefined; // undefined类型 let n: null = null; // null类型 基本上都与 JavaScript 相似,可以去看我之前写的 JavaScript数据类型。从基础的 boolean、number、string,到复杂的 enum、tuple、unknown,TypeScript 让每个变量都有了明确的 “身份”。这里有一个注意的点就是 unknown 类型 和 any类型。unknown 类型不能直接赋值给其他类型,而 any 类型可以随便变,所以下次报错的时候看看,是不是这个原因。五、对象与类型:不是所有空对象都一样TypeScript 对对象的类型约束更严格:const obj: object = {}; const obj2: Object = {}; const obj3: {} = {}; // 错误 // obj.a = 1; // 编译错误 // obj3.a = 1; // 编译错误 // 正确(类型断言) (obj2 as any).a = 1; console.log(obj2); // 输出: { a: 1 } const hello = 'hello'; const a: 'hello' = 'hello'; object、Object 和 {} 看似相似,实际约束力度不同;字面量类型更是把变量锁死在特定值上,杜绝了 “意外变身”。六、类型守卫🛡️:给你的代码装上 “火眼金睛”TypeScript 的类型守卫,就像给你的代码配上了一个智能安检员,能在运行时精准识别变量类型。// 类型守卫 interface Person { name: string; age: number; sex?: unknown; // 可选属性,不是每个人都需要填写 } const person: Person = { name: 'henry', age: 18, sex: '男' // 可选属性,写不写都不会报错 }; // 举个类型守卫的例子:判断一个值是不是 Person 类型 function isPerson(value: unknown): value is Person { return ( typeof value === 'object' && value !== null && 'name' in value && 'age' in value ); } function printUserInfo(value: unknown) { if (isPerson(value)) { // 进入这个分支后,TypeScript 就知道 value 是 Person 类型了 console.log(`姓名:${value.name},年龄:${value.age}`); if (value.sex) { console.log(`性别:${value.sex}`); } } else { console.log('这不是一个合法的 Person 对象'); } } printUserInfo(person); // 输出:姓名:henry,年龄:18 printUserInfo({ name: 'lucy' }); // 输出:这不是一个合法的 Person 对象 七、类型转换与组合:灵活不代表放纵如果遇到类型不确定的场景,TypeScript 提供了类型断言来 “手动担保”:let someValue: any = '123'; let strLength = (someValue as string).length; // 写法一 let strLength2 = (someValue).length; // 写法二 还可以用 type 定义联合类型和交叉类型:type Person = string | number | boolean; const a: Person = 'hello'; const b: Person = 123; const c: Person = true; type PartialX = {x: number} type Point = PartialX & {y: number} // 交叉类型:合并多个类型 const p: Point = { x: 10, y: 20 } 八、泛型:写一次,适配所有类型泛型是 TypeScript 的 “秘密武器”,让函数和组件更通用。function identity(value: T) { return value; } identity (100); // 指定 T 为 number 类型 function identity2 (value: T, msg: U): T { console.log(msg); return value; } identity2 (100, 'hello'); // 多泛型参数 let arr: Array = [1, 2, 3]; let arr2: Array = [1, 2, 3, 'hello']; 泛型让 identity 函数既能处理数字,也能处理字符串,不用写多个重复函数,代码复用性直接拉满。结语从 JavaScript 的 “盲盒变量” 到 TypeScript 的 “精准类型”,本质是从 “靠运气写代码” 到 “靠逻辑写代码” 的转变。写的代码都不严谨,那还写什么代码呢😄。TypeScript 不是给你套枷锁,而是给你装护栏 —— 它不会限制你的创造力,只会帮你提前避开那些低级 Bug。所以,不要害怕红色的报错,而是试着去解决它。——转载自:风止何安啊
为什么要有 TypeScript?让 JS 告别 “薛定谔的 Bug”
开源硬件平台
#技术干货# 【摘要】一款基于表格的研发项目管理工具,覆盖概念、系统设计、开发、测试、验收全流程,帮助研发团队规范过程管理、沉淀项目数据、实现需求追溯。适用于汽车电子 ECU 及其他嵌入式系统研发。 在研发项目管理中,你是否遇到过这些问题: 需求、设计、测试数据分散在多个 Excel 文件中,版本难以统一管理 项目成员各自维护自己的表格,信息不同步 需要追溯需求时,要在多个文件之间来回查找关联 项目结项后,经验教训没有系统沉淀,下一个项目继续踩坑 这些问题的核心在于:缺乏一个统一的数据管理平台。 零绪研发项目管理工具,正是为了解决这些问题而设计。 ## 零绪是什么? 零绪是一款基于表格的研发项目管理工具。 它提供标准化的表格模板,覆盖研发项目的完整生命周期:概念阶段、系统设计阶段、开发阶段、测试阶段、验收阶段。 每个阶段包含若干张专业设计的表格,用户通过填写表格完成项目数据的录入和管理。所有数据集中存储,团队成员访问同一份数据,避免多版本混乱。 ### 核心特点 类 Excel 操作体验   如果你熟悉 Excel,就能快速上手零绪。工具采用表格形式呈现,支持单元格编辑、数据筛选等常见操作。 标准化字段设计   每张表格的字段基于 ASPICE、ISO 26262 等行业标准设计,确保数据规范性和完整性。 集中化数据存储   所有项目数据存储在统一平台,支持跨阶段查询和统计,方便团队协作和知识沉淀。 可追溯的数据结构   通过 ID 引用建立需求、设计、测试之间的关联关系,支持追溯查询和覆盖率统计。 ## 零绪能管理什么? 零绪覆盖研发项目的五个核心阶段,每个阶段提供相应的表格模板: 概念阶段——收集客户 SOR 需求,进行可行性评估,定义系统需求,完成 HARA 分析和功能安全目标设定。 系统设计阶段——进行系统架构设计,分解硬件和软件需求,完成关键元器件选型,输出 DFMEA/PFMEA 分析,管理工作进度。 开发阶段——管理软件和硬件的架构设计、详细设计、单元测试用例及执行记录,支持线束定义。 测试阶段——管理集成测试、系统测试(功能/性能/环境/诊断/工况)、功能安全确认测试,覆盖测试计划、用例设计、执行记录全流程。 验收阶段——规划验收测试,记录测试结果和客户意见,生成交付物清单和验收报告,完成项目结项和经验总结。 此外,每个阶段还包含输入评审、输出评审、问题记录、变更管理四张公共表格,用于过程管理和质量控制。 项目信息查询模块提供跨阶段的数据总览,包括需求跟踪矩阵、评审汇总、问题分布统计、变更趋势分析等。 ##零绪如何使用?### 基本操作流程 创建项目:新建项目,填写项目基本信息 选择阶段:根据项目进展进入对应阶段 填写表格:按照字段定义逐项录入数据 建立关联:在关联字段中填写对应 ID,建立追溯关系 评审确认:组织评审并记录结论 问题跟踪:发现问题及时登记并跟踪解决 变更管理:变更时填写变更表,评估影响并实施 ### 数据录入方式 零绪中的数据需要手动录入,这是为了保证数据的准确性和责任明确: 需求描述由系统工程师根据客户 SOR 手工转化 设计内容由开发工程师根据设计方案填写 测试结果由测试工程师根据实际测试情况记录 评审结论由评审参与人员讨论后填写 工具的价值在于提供标准化模板、统一字段定义、集中存储管理、建立ID 引用,让数据录入更规范、查询更便捷、追溯更清晰。 ### 统计与查询 零绪支持多种数据统计和查询: 需求覆盖率统计 问题状态分布 变更趋势分析 进度可视化(甘特图) 追溯链查询 ## 谁适合使用零绪? 适用行业 汽车行业 ECU 研发(发动机控制器、变速箱控制器、车身控制器、网关、BMS、VCU、MCU 等) 其他嵌入式系统研发(工业控制、医疗设备、航空航天、轨道交通等) 团队规模 小型团队(5-10 人):快速建立规范化流程 中型团队(10-30 人):提升协同效率 大型团队(30 人以上):统一工作语言和模板 适用角色 项目经理、系统工程师、硬件工程师、软件工程师、测试工程师、质量工程师。 ## 为什么选择零绪? 专业设计——表格字段基于行业标准设计,符合车规级研发要求。 易于上手——类 Excel 的操作方式,无需复杂培训即可使用。 灵活适配——可根据团队实际需求调整,不强制绑定特定方法论。 持续沉淀——项目数据集中存储,形成组织过程资产。 合规支持——完整的评审记录、追溯关系、问题跟踪,为审核提供证据支持。 更多内容
01_零绪研发项目管理工具
硬创社
最近圈子炸了两次。第一次是Claude Code源码泄露事件。有人把Anthropic的核心代码扔到了GitHub上,虽然官方火速处理,但技术圈已经炸开了锅——大家突然发现,原来AI编程已经进化到了这个程度。第二次更刺激:豆包9块9。对,你没看错,9块9就能用上一个完整的AI编程工具。这价格,连一杯奶茶都买不到,但它已经开始抢程序员的饭碗了。然后就出现了两种声音:1.AI要把程序员干掉了2.AI最终不靠谱,锅还是要人来背的我专门花了三个月研究这件事,结论是——AI确实在抢饭碗,但抢的是另一群程序员的。什么意思?你会发现,现在最慌的不是那些真正写核心逻辑、做架构设计的人,而是那些每天写CRUD、做简单前端页面的"代码搬运工"。AI工具对这部分工作的替代效率,高得可怕。但反过来,那些真正能解决问题、能设计系统、能理解业务的人,AI不是来抢你饭碗的,它是来给你装上火箭助推器的。说白了,AI淘汰的不是程序员,而是低效的编程方式。你还在一个字母一个字母敲代码,别人已经在用AI生成框架、自动写测试、一键优化性能了。差距不是一点半点。(((顺便吆喝一句,技术大厂,前后端-测试机会,全国一线及双一线城市均有坑位坑位,待遇和稳定性还不错,感兴趣可以试试~所以问题来了:你和AI之间,是竞争关系,还是协作关系?这个问题的答案,决定了你是在2026年被淘汰,还是在2026年起飞。#嘉立创PCB#
AI 9块9抢程序员饭碗?我专门研究了三个月,结论可能和你想的不一样
开源硬件平台
这几天折磨死我了,因为这玩意我也是自己在琢磨,然后资料也没有多少,简直就是自己慢慢摸索。 本期介绍如何利用TCP接收图片信息并显示。 首先我们先新建一个类,将我们想要的内容全部写到这个类上(类的代码会放在最后面) cpListener用来创建监听,tcpClient用以发送。public AndroidWifiService() { } ~AndroidWifiService() { tcpClient?.Close(); tcpClient = null; tcpListener = null; MessageReceived = null; } public AndroidWifiService(IPAddress address,int Port) { StartListening(address, Port); } public AndroidWifiService(string address, int Port) { StartListening(IPAddress.Parse(address), Port); } 提供三种类型的构造函数和析构函数。protected virtual void OnMessageReceived(byte[] buffer) { // 触发事件 MessageReceived?.Invoke(this, buffer); } 设置一个事件,用以传递监听到的图片信息。public async void StartListening(IPAddress IP,int Port) { tcpListener = new TcpListener(IP, Port); tcpListener.Start(); while (true) { tcpClient = await tcpListener.AcceptTcpClientAsync(); Task.Run(() => HandleClient(tcpClient)); } } private void HandleClient(TcpClient client) { try { NetworkStream stream = client.GetStream(); byte[] buffer = new byte[1024]; // 使用固定大小的缓冲区 using (MemoryStream ms = new MemoryStream()) { int bytesRead; while ((bytesRead = stream.Read(buffer, 0, buffer.Length)) > 0) { ms.Write(buffer, 0, bytesRead); } if (ms.Length > 0) { // 在主线程上更新 UI MainThread.BeginInvokeOnMainThread(() => { OnMessageReceived(ms.ToArray()); }); } } } catch (Exception ex) { Console.WriteLine($"Exception in HandleClient: {ex.Message}"); } } 创建一个监听函数,注意的是,我们是接受完一次完整的流再传递信息,而不是边接收边传递。private void OnMessageReceived(object sender, byte[] message) { MainThread.BeginInvokeOnMainThread(async () => { try { using (MemoryStream ms = new MemoryStream(message)) { SKBitmap bitmap = SKBitmap.Decode(ms); AndroidSaveClass save = new AndroidSaveClass(); string folderPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Personal), "MAUI_Picture_Save"); if (!save.DoesFolderExist(folderPath)) { Directory.CreateDirectory(folderPath); } // 生成文件路径 string uniqueFileName = $"sample_{DateTime.Now:yyyyMMddHHmmssfff}.png"; string filePath = Path.Combine(folderPath, uniqueFileName); // 将 SKBitmap 编码并保存为 PNG 文件 using (var image = SKImage.FromBitmap(bitmap)) using (var data = image.Encode(SKEncodedImageFormat.Png, 100)) using (var stream = File.OpenWrite(filePath)) { data.SaveTo(stream); } Picture.Source = filePath; } } catch (Exception ex) { Console.WriteLine(ex.ToString()); } }); } 再MainPage.xmal.cs中,我们新建一个这个类的变量,监听我们的窗口。并且设置回调函数用来处理事件。 事件中,我们将图片的字节数组转为图片,之后保存到程序的文件目录中,并且使用时间戳防止图片重复。 之后用Image控件来绑定图片源显示图片。
.NET MAUI的Android WiFi图传开发(3)——Android设备接收TCP信息并显示
嘉立创PCB
01|什么是 Claude Code一句话:👉 Claude Code = 终端里的 AI 执行助手你可以用一句人话,让它帮你:写代码改文件整理资料分析数据自动完成任务📌 和普通 AI 最大区别:ChatGPT:告诉你怎么做 Claude Code:直接帮你做02|快速安装核心只有一句话:👉 先装 Node → 再装 Claude Code安装 Node.jsnodejs.org选择 LTS 版本验证:node -v npm -v安装 Claude Code npm install -g [@anthropic](https://x.com/@anthropic) -ai/claude-code 验证 claude --version 不废话,技术大厂捞人:前端/后端/测试,全国多地可选,待遇和稳定度都在线。→试试试试不吃亏 03|连接国内大模型一、编辑或新增 settings.json 文件MacOS 在.claude文件夹下创建settings.json, ~/.claude/settings.jsonWindows 为用户目录/.claude/settings.json #新增或修改里面的env字段# 注意替换里面的 `your_deepseek_key` 为您上一步获取到的 API Key { "env": { "ANTHROPIC_AUTH_TOKEN": "your_deepseek_key", "ANTHROPIC_BASE_URL":"https://api.deepseek.com/anthropic", "API_TIMEOUT_MS": "3000000", "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": 1, "ANTHROPIC_DEFAULT_HAIKU_MODEL": "glm-4.5-air", "ANTHROPIC_DEFAULT_SONNET_MODEL": "glm-4.7", "ANTHROPIC_DEFAULT_OPUS_MODEL": "glm-4.7" } } 二、再编辑或新增 .claude.json 文件用去跳过MacOS & Linux 为 ~/.claude.jsonWindows 为用户目录/.claude.json #再编辑或新增`.claude.json`文件# 新增 `hasCompletedOnboarding` 参数 { "hasCompletedOnboarding": true } 三、进入ClaudeCode确认首先确认系统默认的模型名称然后输入/status命令查看baseUrl和模型名称,输入命令 /status ——转载自:想不到一个好的ID
Claude Code 初学者必看指南
开源硬件平台
各位工程师、采购和电子爱好者,你是否遇到过这样的问题——选型时拿不准器件的稳定性?量产之后才发现可靠性隐患?其实,民品也一样需要“高可靠”的底气。 这一次,我们邀请了一位“硬核”原厂——火炬电子,用航天同源的可靠性,降维解决民品顽疾,为电子工程师与爱好者提供专业、可靠的选型方案,再也不用为“莫名炸机”和批次不稳头疼! 4月15日 ,立创商城 × 火炬电子开启专场技术直播,深度拆解高可靠电容与功率器件,从航天级标准到工业民用落地,一站式解决选型、可靠性、失效分析等核心难题!现在扫码预约直播后,保存预约截图,点击链接参与互动还有机会得20采购晶!(采购晶可用于抵扣一定比例的现货商品金额,以及兑换采购晶专区的礼品) 直播全程福利狂撒,2000元现金红包、小炬玩偶礼盒、运动毛巾、冷感速干巾、样品册等实物礼品开送!  直播时间4月15日(周三)19:30 直播主题火炬电子电容器功率器件产品推介 直播嘉宾刘芳演 高级应用工程师黄倩萍 高级市场工程师 关于火炬电子 火炬电子始创于1989年,是国家高新技术企业,产品覆盖MLCC、钽电容、超级电容器、功率器件等品类,以高稳定性、高可靠性和长期服役能力著称,广泛应用于航空、航天、船舶、电力、轨道交通、新能源等重点领域与重大工程,为关键核心系统提供安全、稳定的基础支撑。 直播核心亮点 航天级电容解析:MLCC、钽电容、超级电容的高可靠设计与选型标准;功率器件硬核科普:MOS/SiC MOS等高可靠方案与工业/新能源应用;可靠性实战指南:电容失效、压电效应、金脆效应等问题一站式解决; 在线实时答疑:火炬电子嘉宾解答高可靠元器件选型、测试、应用疑问,若你的问题被嘉宾挑中回答,还可以获得立创送出的采购晶! 无论您在做电源、工控、汽车还是消费类产品,这场直播将帮您选对器件、提升产品可靠性。 立即预约,4月15日19:30,立创商城视频号见!
原厂揭秘:火炬电子高可靠产品推介,预约锁定专属福利
立创商城
电池包的热管理,是新能源汽车安全与续航的核心命脉。当电芯在大倍率充放电时,瞬间产生的热量若无法及时导出,不仅会导致电池加速衰减,更可能引发热失控风险。而在热管理系统中,一个小小的导热界面材料——导热硅脂,却常常成为决定成败的关键。 今天,我们将目光聚焦于华东某知名新能源汽车制造商的电池包散热改造项目。这是傲琪电子以专业热管理方案解决客户痛点、实现性能跃升的典型案例。   一、 项目背景:被忽视的“界面之困” 该车企在研发一款高能量密度电池包时,遇到了棘手的散热瓶颈。其设计方案采用液冷板贴合模组底部的方式散热,但在测试中发现:即使液冷板温度控制良好,电芯底部的温度依然居高不下,导致电池包整体温差超过8℃,严重影响了电池的一致性与循环寿命。 问题出在哪里?经过热成像分析与拆解,根源锁定在电芯与液冷板之间的导热界面。 电芯铝壳与液冷板表面虽然经过机加工,但微观上仍存在大量凹凸不平的缝隙。为了填充这些缝隙,原方案使用了一种常规导热垫片。然而,垫片硬度偏高,无法完全贴合曲面;且长期受压后,垫片发生应力松弛,接触热阻逐渐增大,导致热量“堵”在了电芯底部。 二、 傲琪方案:不仅仅是“换一种材料” 接到客户诉求后,傲琪电子技术团队立即介入。我们没有简单地推荐一款高导热系数的硅脂,而是从界面传热机理与工程可制造性两个维度展开分析。 1. 材料匹配:低热阻与长期稳定性并重 针对电池包内部空间狭小、长期震动、温度交变的特点,傲琪电子推荐了G500系列高导热硅脂作为核心填充材料,并配合导热灌封胶实现整体密封与散热。 G500系列导热硅脂:导热系数5.0W/(m·K),远高于常规垫片。其独特的低油离度(<0.05%) 配方确保了在40℃~150℃的极端温度循环中,基础油不会析出污染电芯极柱或连接器,避免了传统硅脂“泵出效应”导致的干涸失效。 导热灌封胶:在电池包底部形成一层兼具绝缘、导热、缓冲的整体密封层,将电芯产生的热量高效传导至液冷板,同时起到防护作用。 2. 工艺适配:实现微米级均匀涂覆 大尺寸电池模组对涂覆均匀性要求极高。傲琪团队协助客户改进了涂覆工艺:采用精密钢网印刷,将G500硅脂以80μm的厚度精准涂布在液冷板表面,确保了每个电芯底部接触面的热阻一致。随后,在模组装配时注入导热灌封胶,利用胶体的流动性二次填充细微间隙,形成“无死角”的导热网络。  三、 落地成果:热阻直降30%,温差缩至3℃ 改造后的电池包经历了严苛的第三方测试,数据令人振奋: 界面热阻降低30%:相比原垫片方案,G500硅脂与灌封胶的组合将接触热阻从0.62℃·in²/W降至0.43℃·in²/W。 最高温度下降8℃:在2C倍率连续充放电测试中,电芯最高温度由72℃降至64℃,有效延缓了电池衰减。 温差控制优于3℃:模组内各电芯间的最大温差从8℃以上缩小至2.8℃,大幅提升了电池一致性与循环寿命。 长期可靠性验证:经过1000小时高温高湿及500次冷热冲击,材料无开裂、无渗油,接触热阻变化小于5%。 客户热管理负责人感慨:“之前我们一直在垫片和硅脂之间犹豫,总以为垫片更可靠。傲琪用实测数据告诉我们,选对材料、做对工艺,硅脂不仅能胜任,还能带来意想不到的性能提升。现在这款电池包已经成功搭载在我们新款车型上。” 四、 技术解析:为什么傲琪能赢? 这个项目的成功,源于傲琪电子对导热材料底层技术的深耕: 填料复配技术:通过微米与纳米级导热填料的级配填充,G500系列在保证低粘度涂覆性的同时,构建了密集的导热通路,实现高导热与低接触热阻的平衡。 流变学设计:针对印刷工艺需求,精确控制硅脂的触变指数,确保涂覆时易刮平、停顿时不流淌、受压时不外溢。 系统级思维:不孤立看待单一材料,而是提供“硅脂+灌封胶+工艺优化”的组合方案,解决客户从材料到量产的全链条问题。 结语 新能源汽车的热管理是一场“毫米级”的较量,每一个界面的优化都关乎整车的安全与效能。傲琪电子在电池包项目中的实战证明:小小的导热硅脂,经过专业选型与精密工艺的加持,足以成为攻克散热瓶颈的利器。  
让电池包安然度过“火炉”与“极寒”: 傲琪电子高导热硅脂在新能源汽车热管理中的实战记
开源硬件平台
还在为每个列表页写重复的分页代码而烦恼吗? 还在复制粘贴 currentPage、pageSize、loading 等状态吗? 一个 Hook 帮你解决所有分页痛点,减少90%重复代码背景与痛点在后台管理系统开发中,分页列表查询非常常见,我们通常需要处理:当前页、页大小、总数等分页状态加载中、错误处理等请求状态搜索、刷新、翻页等分页操作数据缓存和重复请求处理这些重复逻辑分散在各个组件中,维护起来很麻烦。为了解决这个烦恼,我专门封装了分页数据管理 Hook。现在只需要几行代码,就能轻松实现分页查询,省时又高效,减少了大量重复劳动使用前提 - 接口格式约定查询接口返回的数据格式: { list: [ // 当前页数据数组 { id: 1, name: 'user1' }, { id: 2, name: 'user2' } ], total: 100 // 数据总条数 } 先看效果:分页查询只需几行代码! import usePageFetch from '@/hooks/usePageFetch' // 引入分页查询 Hook,封装了分页逻辑和状态管理 import { getUserList } from '@/api/user' // 引入请求用户列表的 API 方法 // 使用 usePageFetch Hook 实现分页数据管理 const { currentPage, // 当前页码 pageSize, // 每页条数 total, // 数据总数 data, // 当前页数据列表 isFetching, // 加载状态,用于控制 loading 效果 search, // 搜索方法 onSizeChange, // 页大小改变事件处理方法 onCurrentChange // 页码改变事件处理方法 } = usePageFetch( getUserList, // 查询API { initFetch: false } // 是否自动请求一次(组件挂载时自动拉取第一页数据) ) 这样子每次分页查询只需要引入hook,然后传入查询接口就好了,减少了大量重复劳动【顺便提一嘴】技术大厂,前端-后端-测试,全国均有机=会,感兴趣可以试试。待遇和稳定性都还不错~解决方案我设计了两个相互配合的 Hook:useFetch:基础请求封装,处理请求状态和缓存usePageFetch:分页逻辑封装,专门处理分页相关的状态和操作 usePageFetch (分页业务层) ├── 管理 page / pageSize / total 状态 ├── 处理搜索、刷新、翻页逻辑 ├── 统一错误处理和用户提示 └── 调用 useFetch (请求基础层) ├── 管理 loading / data / error 状态 ├── 可选缓存机制(避免重复请求) └── 成功回调适配不同接口格式 核心实现useFetch - 基础请求封装 // hooks/useFetch.js import { ref } from 'vue' const Cache = new Map() /** * 基础请求 Hook * @param {Function} fn - 请求函数 * @param {Object} options - 配置选项 * @param {*} options.initValue - 初始值 * @param {string|Function} options.cache - 缓存配置 * @param {Function} options.onSuccess - 成功回调 */ function useFetch(fn, options = {}) { const isFetching = ref(false) const data = ref() const error = ref() // 设置初始值 if (options.initValue !== undefined) { data.value = options.initValue } function fetch(...args) { isFetching.value = true let promise if (options.cache) { const cacheKey = typeof options.cache === 'function' ? options.cache(...args) : options.cache || `${fn.name}_${args.join('_')}` promise = Cache.get(cacheKey) || fn(...args) Cache.set(cacheKey, promise) } else { promise = fn(...args) } // 成功回调处理 if (options.onSuccess) { promise = promise.then(options.onSuccess) } return promise .then(res => { data.value = res isFetching.value = false error.value = undefined return res }) .catch(err => { isFetching.value = false error.value = err return Promise.reject(err) }) } return { fetch, isFetching, data, error } } export default useFetch usePageFetch - 分页逻辑封装 // hooks/usePageFetch.js import { ref, onMounted, toRaw, watch } from 'vue' import useFetch from './useFetch' // 即上面的hook ---> useFetch import { ElMessage } from 'element-plus' /** * 分页数据管理 Hook * @param {Function} fn - 请求函数 * @param {Object} options - 配置选项 * @param {Object} options.params - 默认参数 * @param {boolean} options.initFetch - 是否自动初始化请求 * @param {Ref} options.formRef - 表单引用 */ function usePageFetch(fn, options = {}) { // 分页状态 const page = ref(1) const pageSize = ref(10) const total = ref(0) const data = ref([]) const params = ref() const pendingCount = ref(0) // 初始化参数 params.value = options.params // 使用基础请求 Hook const { isFetching, fetch: fetchFn, error, data: originalData } = useFetch(fn) // 核心请求方法 const fetch = async (searchParams, pageNo, size) => { try { // 更新分页状态 page.value = pageNo pageSize.value = size params.value = searchParams // 发起请求 await fetchFn({ page: pageNo, pageSize: size, // 使用 toRaw 避免响应式对象问题 ...(searchParams ? toRaw(searchParams) : {}) }) // 处理响应数据 data.value = originalData.value?.list || [] total.value = originalData.value?.total || 0 pendingCount.value = originalData.value?.pendingCounts || 0 } catch (e) { console.error('usePageFetch error:', e) ElMessage.error(e?.msg || e?.message || '请求出错') // 清空数据,提供更好的用户体验 data.value = [] total.value = 0 } } // 搜索 - 重置到第一页 const search = async (searchParams) => { await fetch(searchParams, 1, pageSize.value) } // 刷新当前页 const refresh = async () => { await fetch(params.value, page.value, pageSize.value) } // 改变页大小 const onSizeChange = async (size) => { await fetch(params.value, 1, size) // 重置到第一页 } // 切换页码 const onCurrentChange = async (pageNo) => { await fetch(params.value, pageNo, pageSize.value) } // 组件挂载时自动请求 onMounted(() => { if (options.initFetch !== false) { search(params.value) } }) // 监听表单引用变化(可选功能) watch( () => options.formRef, (formRef) => { if (formRef) { console.log('Form ref updated:', formRef) } } ) return { // 分页状态 currentPage: page, pageSize, total, pendingCount, // 数据状态 data, originalData, isFetching, error, // 操作方法 search, refresh, onSizeChange, onCurrentChange } } export default usePageFetch 完整使用示例用element ui举例 <template> <el-form :model="searchForm" > <el-form-item label="用户名"> <el-input v-model="searchForm.username" /> </el-form-item> <el-form-item> <el-button type="primary" @click="handleSearch">搜索</el-button> </el-form-item> </el-form> <!-- 表格数据展示,绑定 data 和 loading 状态 --> <el-table :data="data" v-loading="isFetching"> <!-- ...表格列定义... --> </el-table> <!-- 分页组件,绑定当前页、页大小、总数,并响应切换事件 --> <el-pagination v-model:current-page="currentPage" v-model:page-size="pageSize" :total="total" @size-change="onSizeChange" @current-change="onCurrentChange" /> </template> <script setup> import { ref } from 'vue' import usePageFetch from '@/hooks/usePageFetch' // 引入分页查询 Hook,封装了分页逻辑和状态管理 import { getUserList } from '@/api/user' // 引入请求用户列表的 API 方法 // 搜索表单数据,响应式声明 const searchForm = ref({ username: '' }) // 使用 usePageFetch Hook 实现分页数据管理 const { currentPage, // 当前页码 pageSize, // 每页条数 total, // 数据总数 data, // 当前页数据列表 isFetching, // 加载状态,用于控制 loading 效果 search, // 搜索方法 onSizeChange, // 页大小改变事件处理方法 onCurrentChange // 页码改变事件处理方法 } = usePageFetch( getUserList, { initFetch: false } // 是否自动请求一次(组件挂载时自动拉取第一页数据) ) /** * 处理搜索操作 */ const handleSearch = () => { search({ username: searchForm.value.username }) } </script> 高级用法带缓存 const { data, isFetching, search } = usePageFetch(getUserList, { cache: (params) => `user-list-${JSON.stringify(params)}` // 自定义缓存 key }) 设计思路解析职责分离:useFetch 专注请求状态管理,usePageFetch 专注分页逻辑统一错误处理:在 usePageFetch 层统一处理错误智能缓存机制:支持多种缓存策略生命周期集成:自动在组件挂载时请求数据总结这套分页管理 Hook 的优势:开发效率高,减少90%的重复代码,新增列表页从 30 分钟缩短到 5 分钟状态管理完善,自动处理加载、错误、数据状态缓存机制,避免重复请求错误处理统一,用户体验一致易于扩展,支持自定义配置和回调——转载自:不一样的少年_
Vue3 后台分页写腻了?我用 1 个 Hook 删掉 90% 重复代码(附源码)
开源硬件平台
SMT贴片加工是将电子元器件焊接到PCB上,那么在进行贴片加工之前都是需要对PCB进行检测,挑选以符合SMT生产要求的PCB,并且把不合格的退回PCB供应商,PCB的具体要求可以参考IPc-a-610c 国际通用电子行业组装标准,下面是一些SMT贴片加工对PCB的基本要求。外观与平整度表面平整光滑:PCB板应无翘曲、高低不平,否则在锡膏印刷和贴片时可能出现裂痕、影响钢网和刮刀寿命等问题。无污垢和氧化层:表面不能有污垢、锈斑、氧化等,以免影响定位、贴装和焊接质量。清洁度良好:能承受清洁剂清洗,在液体中浸渍5分钟表面不产生不良,且有良好的冲载性。尺寸与形状合适的外形尺寸:一般尺寸在50×50~350×250mm,但不同SMT设备要求有差异,设计时需考虑设备的最大和最小贴装尺寸。规则的形状:通常为矩形,最佳长宽比为3:2或4:3,长宽比例较大时容易产生翘曲变形。传送边要求:传送边不能有缺口,拐角要做圆形倒角,元器件最外侧距传送边≥3mm,尽量保证5mm,否则需加工艺边。板材与性能导热性良好:导热系数一般在0.2-0.8W/(K·m),整个PCB平均导热系数约6.5W/(m·K),以便在回流焊和波峰焊时受热均匀。耐热性达标:无铅工艺回流焊接温度达217245℃,持续3065s,PCB耐热性要达到260摄氏度持续10s。铜箔粘合强度足够:铜箔的粘合强度要达1.5kg/cm²,防止外力作用导致铜箔脱落。良好的导电性:作为电子元器件的载体,PCB需依靠线路导通实现元器件间连接,线路不能有断路等问题。Mark点设置形状与大小:形状标准有圆形、正方形、三角形等,大小在1.0~2.0mm。表面要求:表面平整、光滑、无氧化、无污物,与周围颜色有明显差异。位置要求:距离板边3mm以上,周围5mm内不能有类似mark点、过孔、测试点等,为避免进板方向错误,左右两边mark点与板缘位置差别应在10mm以上。拼版设计板边宽度与间距:拼版的板边宽度3~5mm,间距在1.6mm以上。弯曲与扭曲度:向上弯曲程度<1.2mm,向下弯曲程度<0.5mm,扭曲度最大变形高度÷对角长度<0.25。分板方式:拼板之间可采用V形槽、邮票孔或冲槽等,建议同一板只用一种分板方式。焊盘设计尺寸与形状:焊盘尺寸要合适,不能过大或过小,形状需符合元器件封装要求,参照数据手册设计。无过线孔与漏锡孔:焊盘上不能有过线孔,元器件焊盘边不能有漏锡孔,避免焊接时出现锡珠、短路等问题。阻焊与丝印阻焊层:阻焊层不能高于焊盘,且平坦,不影响焊盘,以保证锡膏印刷和焊接的准确性。丝印清晰:丝印要清晰可见,方便设备和操作员准确检测元器件位置和焊盘方向。
SMT贴片加工对PCB的基本要求
嘉立创SMT
单位:px、em、rem、vw、vh、clamp 怎么选?CSS 单位是响应式布局的核心,也是我刚学响应式时踩坑最多的知识点之一——明明写好的尺寸,换个屏幕、调个字体大小就错乱,排查后才发现是单位选得不对。px 是固定值、em/rem 是相对值、vw/vh 跟着视口走、clamp 能做流体排版,掌握它们的区别和用法,响应式开发、页面可访问性都会轻松很多。今天就把我整理的单位干货、实操经验和避坑技巧,分享给大家。一、绝对单位:px 为主,其他慎用(我的日常用法)绝对单位里,我日常开发只用 px(像素),其他单位(mm、cm、in、pt 等)几乎用不到,大多用于打印场景,新手不用花太多精力记忆。 /* px:像素,固定值,不会随任何因素变化 */ font-size: 16px; width: 200px; /* 打印场景专用,日常开发基本用不上 */ mm, cm, in, pt 分享我的实操心得:px 最适合用来设置固定不变的尺寸,比如边框宽度、小间距、图标大小、圆角等,这些地方不需要随字体、视口缩放,用 px 最精准,也最不容易出错。我早期曾用 em 设边框,结果字体一调,边框也跟着变粗,踩过一次坑后就再也不这么做了。二、相对单位:em 好用但易踩坑,嵌套需谨慎em 是相对单位,核心是“相对于当前元素的 font-size”——如果当前元素没设置 font-size,就继承父级的 font-size,这也是它容易踩坑的地方。 .parent { font-size: 16px; } .child { font-size: 1.5em; /* 相对于父级16px,就是24px */ padding: 1em; /* 重点:相对于自己的font-size(24px),就是24px */ margin: 0.5em; /* 相对于自己的font-size,就是12px */ } /* 嵌套会累积,这是我踩过的大坑! */ .grandchild { font-size: 1.2em; } /* 相对于子元素24px,就是28.8px,越嵌套越大 */ 避坑提醒:em 最大的问题就是“嵌套累积”,嵌套层级越深,计算出来的尺寸越乱,我早期做导航菜单嵌套时,用 em 设字体,结果二级、三级菜单字体越变越大,排查了很久才找到原因。现在我只用 em 做简单的局部适配,嵌套场景坚决不用。三、相对单位:rem 我的首选,全局缩放超省心后来接触到 rem,直接解决了 em 嵌套累积的痛点!rem 也是相对单位,但它只相对于根元素(html)的 font-size,和父级元素没有关系,不会出现嵌套累积的问题,现在是我做全局布局、字体设置的首选单位。 /* 根元素字体大小,默认通常是16px,我会明确设置,避免浏览器差异 */ html { font-size: 16px; } .box { font-size: 1rem; /* 相对于html的16px,就是16px */ padding: 1.5rem; /* 16px×1.5=24px,计算直观 */ width: 20rem; /* 16px×20=320px,不用复杂换算 */ } /* 响应式神器:只需修改根字号,全站元素就会等比缩放 */ @media (max-width: 768px) { html { font-size: 14px; } /* 小屏缩小根字号,字体、间距、布局同步缩小 */ } 我的实操用法:rem 适合设置字体大小、容器间距、布局宽度等需要全局适配的样式,配合媒体查询修改根元素 font-size,就能轻松实现全站等比缩放,不用逐个修改每个元素的尺寸,效率大幅提升。#嘉立创PCB#<顺便提一嘴>技术大厂,前端-后端-测试,全国均有机=会,感兴趣可以试试。待遇和稳定性都还不错~四、视口单位:vw、vh、vmin、vmax 做全屏/自适应超方便视口单位是相对于“视口(浏览器可见区域)”的尺寸,和元素、根元素都无关,适合做全屏布局、自适应组件,比如首页Banner、全屏弹窗等,是响应式布局的“好帮手”。 /* vw:视口宽度的 1%,视口宽1000px,1vw就是10px */ .full-width { width: 100vw; } /* 占满视口宽度 */ .half-width { width: 50vw; } /* 占视口宽度的一半 */ /* vh:视口高度的 1%,视口高800px,1vh就是8px */ .full-height { height: 100vh; } /* 占满视口高度 */ /* vmin:vw 和 vh 里较小的那个,适合做正方形自适应 */ .square { width: 50vmin; height: 50vmin; } /* 始终是正方形,随视口缩放 */ /* vmax:vw 和 vh 里较大的那个,适合做全屏英雄区 */ .hero { height: 100vmax; } 高频坑点:这几个单位我踩过两个关键的坑,一定要记牢!1. 100vw 会包含浏览器滚动条的宽度,如果页面有纵向滚动条,用 100vw 会导致横向溢出,出现横向滚动条;2. 移动端用 100vh 时,浏览器地址栏显隐会导致高度跳动,体验很差,后来发现用 dvh 就能解决。五、现代视口单位:dvh、svh、lvh 解决移动端高度跳动问题为了解决传统 vh 在移动端的痛点,浏览器新增了 dvh、svh、lvh 三个现代视口单位,我现在做移动端全屏布局,全靠它们,再也不会出现高度跳动的问题。 /* dvh:动态视口高度,地址栏显隐时会自动调整高度,最常用、最推荐 */ .min-height: 100dvh; /* 移动端全屏布局首选,适配所有场景 */ /* svh:小视口高度,仅当浏览器地址栏始终可见时的视口高度 */ .min-height: 100svh; /* lvh:大视口高度,仅当浏览器地址栏始终隐藏时的视口高度 */ .min-height: 100lvh; 我的实操建议:做移动端全屏页面、吸底组件时,优先用 dvh,它能自动适配地址栏的显隐,保证页面高度始终贴合视口,体验更流畅;svh 和 lvh 只用在特殊场景,日常开发很少用到。六、clamp:流体排版神器,不用媒体查询也能自适应clamp 是我近期最常用的“黑科技”,它能实现“流体排版”,语法很简单:clamp(最小值, 首选值, 最大值),意思是在最小值和最大值之间,根据首选值随视口平滑变化,不用写一堆媒体查询,就能实现自适应,极大减少代码量。 /* 字体:最小1.5rem(24px),最大2.5rem(40px),随视口宽度平滑变化 */ h1 { font-size: clamp(1.5rem, 4vw + 1rem, 2.5rem); } /* 容器:最小320px(小屏不挤),最大1200px(大屏不宽),随视口自适应 */ .container { width: clamp(320px, 90vw, 1200px); margin: 0 auto; /* 水平居中,适配所有屏幕 */ } /* 间距:小屏16px,大屏24px,随视口同步变化,不用单独写媒体查询 */ .section { padding: clamp(16px, 5vw, 24px); } 我的实操技巧:首选值常用 vw + rem 或 calc 做线性变化,比如 4vw + 1rem,既能保证小屏有足够的尺寸,又能让大屏尺寸不夸张;clamp 适合设置字体、容器宽度、间距等需要“平滑自适应”的样式,比媒体查询更简洁、更流畅。七、百分比 %:相对父级,布局常用但易踩坑百分比 % 也是相对单位,核心是“相对于父级元素的 content 区域尺寸”,日常布局用得很多,但新手容易踩坑,尤其是高度设置。 .child { width: 50%; /* 相对于父级content宽度的50%,布局常用 */ height: 100%; /* 相对于父级content高度的100%,容易失效 */ padding: 10%; /* 重点:margin、padding的%,始终相对父级宽度,不是高度! */ } 避坑提醒:这是我早期踩过的高频坑——子元素设置 height: 100% 时,如果父级元素没有明确设置高度(比如父级 height 为 auto),子元素的 100% 就会失效,显示为内容高度。另外,margin 和 padding 的百分比,不管是水平还是垂直方向,都相对于父级的宽度,不是高度,新手很容易记混。八、我的实际用法建议(直接套用,少踩坑)结合我多年的开发经验,整理了一套单位使用规范,新手可以直接套用,不用再纠结怎么选,高效又避坑: /* 1. 根字号:设置rem基准,避免浏览器差异 */ html { font-size: 16px; } /* 2. 字体:rem(全局统一)或 clamp(流体自适应) */ body { font-size: 1rem; } /* 全局基础字体 */ h1 { font-size: clamp(1.5rem, 2vw + 1rem, 2.5rem); } /* 标题流体排版 */ /* 3. 间距:rem为主,保证全局一致性,配合clamp做自适应间距 */ .gap { gap: 1rem; } .padding { padding: 1.5rem; } .section-padding { padding: clamp(16px, 5vw, 24px); } /* 4. 布局宽度:%(局部适配)、vw、clamp(全局自适应) */ .container { width: min(90vw, 1200px); } /* 结合min更稳妥 */ .child-box { width: 50%; } /* 父级容器内的局部适配 */ /* 5. 小固定值:px(精准不变) */ border: 1px solid #eee; /* 边框固定 */ border-radius: 4px; /* 圆角固定 */ .icon-size { width: 24px; height: 24px; } /* 图标固定尺寸 */ /* 6. 全屏布局:dvh(移动端)、vh(PC端) */ .full-screen { min-height: 100dvh; } /* 移动端全屏首选 */ 九、个人总结:单位选择避坑核心(新手必看)固定尺寸用 px:边框、圆角、小图标、固定间距,精准不混乱;全局适配用 rem:字体、全局间距、布局,配合媒体查询改根字号,全站等比缩放;嵌套场景避 em:em 易累积,只用在简单局部适配,嵌套层级深的场景坚决不用;全屏/视口适配用 vw/vh + dvh:PC端用 vw/vh,移动端全屏用 dvh,避免高度跳动;流体排版用 clamp:字体、容器宽度、自适应间距,不用媒体查询,简洁又流畅;百分比慎用:记住“宽高相对父级、边距相对父级宽度”,父级无明确高度时,height: 100% 会失效。其实单位选择没有绝对的对错,核心是结合场景,保证页面适配流畅、维护便捷。我从一开始分不清各种单位,到现在能熟练搭配使用,核心就是多实操、多踩坑、多总结,新手只要记住上面的规则,就能少走很多弯路。——转载自:VixenAhri
单位:px、em、rem、vw、vh、clamp 怎么选?
开源硬件平台
社区数据
今日帖子
-
今日互动量
-
在线人数
-
帖子总量
-
用户总量
-
功能讨论
()
主题
打赏记录
服务时间:周一至周六 9::00-18:00 · 联系地址:中国·深圳(福田区商报路奥林匹克大厦27楼) · 媒体沟通:pr@jlc.com · 集团介绍
移动社区