嘉立创社区
发动态
综合 最新发布 最新回复
图文
列表
置顶
【点击参与免费领券】
置顶
超100万奖金池！电子DIY爱好者必参加的活动！
开源硬件平台
 XL5300TOF直接飞行时间（dToF）传感器采用单模块封装设计，集成了单光子雪崩二极管（SPAD）接收阵列以及VCSEL激光发射器。该传感器可对物体进行精确的距离测量而不受物体颜色、反射率和纹理的影响，为市场上的微型ToF 传感提供了紧凑的解决方案。利用自主研发的 SPAD 和独特的ToF 采集与处理技术，XL5300TOF 可实现最大 4 米的精确距离测量，快速测距频率可达 90 Hz。该传感器内置了基于直方图的算法，能够对玻璃罩进行校准并补偿污渍或污染物，从而实现稳定可靠的运行。其采用了亚纳秒光脉冲和特殊的人眼安全控制电路，符合 1 类人眼安全标准的要求。该传感器通过窄带滤光片和内置的阳光抑制算法将环境光噪声降到最低，可用于室外阳光环境下的距离测量。测量数据及系统配置信息通过 I2C 快速模式通信接口进行传输。该传感器易于系统集成，使用单电源供电，且不需要额外的光学元件。应用• 激光检测自动对焦（LDAF）• 接近感应• 避障与防撞• 1D 手势识别• 低功耗系统运行时的物体检测• 智能手机/平板• 车载导航等领域• 台灯• 摄像头快速聚焦辅助• 人员经过、闯入检测• 无人机定高、避障
XL5300 近距离测距模块介绍
开源硬件平台
最近圈子炸了两次。第一次是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抢程序员饭碗？我专门研究了三个月，结论可能和你想的不一样
开源硬件平台
开源硬件平台
这两个行不行？ p1屏谱 p2主板
开源硬件平台
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 初学者必看指南
开源硬件平台
3255发烧功放板 有对3255功放板感兴趣的吗
71次播放
开源硬件平台
电池包的热管理，是新能源汽车安全与续航的核心命脉。当电芯在大倍率充放电时，瞬间产生的热量若无法及时导出，不仅会导致电池加速衰减，更可能引发热失控风险。而在热管理系统中，一个小小的导热界面材料——导热硅脂，却常常成为决定成败的关键。 今天，我们将目光聚焦于华东某知名新能源汽车制造商的电池包散热改造项目。这是傲琪电子以专业热管理方案解决客户痛点、实现性能跃升的典型案例。   一、 项目背景：被忽视的“界面之困” 该车企在研发一款高能量密度电池包时，遇到了棘手的散热瓶颈。其设计方案采用液冷板贴合模组底部的方式散热，但在测试中发现：即使液冷板温度控制良好，电芯底部的温度依然居高不下，导致电池包整体温差超过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系列在保证低粘度涂覆性的同时，构建了密集的导热通路，实现高导热与低接触热阻的平衡。 流变学设计：针对印刷工艺需求，精确控制硅脂的触变指数，确保涂覆时易刮平、停顿时不流淌、受压时不外溢。 系统级思维：不孤立看待单一材料，而是提供“硅脂+灌封胶+工艺优化”的组合方案，解决客户从材料到量产的全链条问题。 结语 新能源汽车的热管理是一场“毫米级”的较量，每一个界面的优化都关乎整车的安全与效能。傲琪电子在电池包项目中的实战证明：小小的导热硅脂，经过专业选型与精密工艺的加持，足以成为攻克散热瓶颈的利器。  
让电池包安然度过“火炉”与“极寒”： 傲琪电子高导热硅脂在新能源汽车热管理中的实战记
开源硬件平台
铁电U盘，分享 https://oshwhub.com/fangs233/project_blcrwqhk
开源硬件平台
还在为每个列表页写重复的分页代码而烦恼吗？ 还在复制粘贴 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% 重复代码（附源码）
开源硬件平台
小太空人比起背包你更喜欢哪个 #嘉立创PCB# #DIY设计# #嘉立创EDA#
104次播放
开源硬件平台
开源硬件平台
单位：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 怎么选？
开源硬件平台
有没有DC-DC升压电路的原理图，带单片机驱动的那种 #嘉立创EDA#
开源硬件平台
项目需求:农村老人因精神障碍拒绝佩戴手机或手表等设备，求助开发定位器 1. **待机/休眠状态**：平时设备为待机/休眠状态，低功耗模式（关闭GPS，降低4G功耗）。 2. **任务查询**：设备每隔一段时间（2小时）联网查询一次服务器接口，“是否有定位任务？”。如果有，则执行定位；如果没有，继续休眠。 3. **定位执行**：如果有任务 -> 打开GPS电源 -> 定位（读取NMEA数据解析经纬度） -> 关闭GPS -> 通过HTTP POST将数据发给服务器。（每十分钟发送一次） 4. **任务结束**：管理端关闭任务，设备继续进入休眠。 设备端 API接口说明： 1. 任务检查接口 - **URL**：`devices.php?action=check_task&id={deviceId}` - **方法**：GET - **功能**：设备查询是否有定位任务 - **返回**：JSON格式的任务状态数据` 2. 定时设置获取接口 - **URL**：`devices.php?action=get_timer_settings` - **方法**：GET - **功能**：获取设备的定时设置（待机查询间隔和任务上报间隔） - **返回**：JSON格式的定时设置数据 3. 任务上报接口 - **URL**：`devices.php?action=report_task&id={deviceId}&lat={latitude}&lng={longitude}` - **方法**：GET - **参数**：`id`（设备ID）, `lat`（纬度）, `lng`（经度） - **功能**：设备上报定位数据 - **返回**：JSON格式的操作结果 软件需求本人可以搞定，求助推荐一款成品或半成品设备，感谢。 #DIY设计# #技术干货#
开源硬件平台
 2.4G 翻页笔由一个 RF 射频遥控器与一个无线接收器（USB 接口）组成。RF 射频遥控器内嵌有无线 RF 射频发射器，在使用时只需要将接收器插入电脑主机的 USB 接口，无需安装驱动即可正常工作。使用者只需点击 RF 射频遥控器的相关功能键便可操纵接收器，并且发射器不用对准接收器，真正体现无线自由。本翻页笔无线控制方案基于深圳市芯岭技术有限公司 XL2417D与 XL2417U 两款高性能、低功耗 2.4G 射频系统级芯片（SoC）搭建，采用XL2417D 作为发射端集成于翻页笔手持端，XL2417U 作为接收端适配电脑、平板等终端设备，核心通过 2.4G 无线通信完成翻页、激光指示等控制指令的高速稳定，传输传输距离约 200 米，接收端则依托 XL2417U 原生集成的 USB 2.0 全速协议，直接实现与终端的指令对接及执行。整体方案兼具硬件设计简洁、功耗低、抗干扰性强、适配性广的特点，完全满足办公、教学等场景下翻页笔的无线控制需求.深圳市芯岭技术有限公司是一家专注于短距离无线通讯，芯片应用解决方案商，从事芯片研发、封测，代理、技术服务、销售，为众多企业提供物联网应用芯片，技术支持，解决方案服务。
芯岭技术两颗芯片结合实现2.4G翻页笔，全部资料开源
开源硬件平台
开源硬件平台
去官网查看
优质硬件创作分享平台
打赏记录
激励规则
服务时间：周一至周六 9::00-18:00 · 联系地址：中国·深圳（福田区商报路奥林匹克大厦27楼） · 媒体沟通：pr@jlc.com · 集团介绍
移动社区
联系我们