发动态
综合 最新发布 最新回复
图文
列表
记录一次把「标题、描述、背景图」全部做成“流体响应式”的踩坑与经验背景最近给 LUCI OS 官网做首屏改版,需求只有一句话:“PC 端浏览器随意缩放,首屏内容要像海报一样,几乎看不出形变。”听起来简单,但「缩放不变形」+「多端自适应」本质上是矛盾的。 经过 3 轮迭代,我们把问题拆成了 4 个小目标,并给出了最简洁的解法。1. 文本:用 clamp() 一把梭传统写法给 3~4 个断点写死字号,窗口稍微拉一下就会跳变。 CSS 4 级函数 clamp(MIN, VAL, MAX) 天生就是解决“跳变”的:标题:text-[clamp(28px,6vw,48px)]描述:text-[clamp(14px,1.2vw,18px)]一行代码实现「最小值保底、最大值封顶、中间平滑变化」。 浏览器缩放时,字号随 vw 线性变化,肉眼几乎察觉不到阶梯感。2. 容器:限宽 + 居中 = “锁死”水平形变再漂亮的字号,如果容器宽度跟着窗口无限拉伸,一样会崩。 做法简单粗暴: max-w-6xl mx-auto max-w-6xl 把最大内容宽度锁死在 1152px;mx-auto 保证左右留白始终对称。窗口继续拉大,两侧只是等比留空,内容区不再变形。3. 图片(或背景):固定尺寸 + 背景定位背景图不能跟着 100% 拉伸,否则人物/产品会被拉长。 我们把背景拆成两层:外层:全屏 div,只做黑色渐变遮罩;内层:真正的背景图用css复制 background: url(...) 50% / cover no-repeat; max-width: 1280px; max-height: 800px; 只要窗口没超过 1280×800,背景图始终保持原始比例,居中裁剪。机-会技术大厂,前端-后端-测试,全国均有机-会,感兴趣可以试试。待遇和稳定性都还不错~4. 布局:断点内“锁死”,断点外才变化Tailwind 的 md:flex-row 之类前缀只在跨断点时生效。 在 同一断点内 我们故意:用固定 gap-32px 而非百分比;用固定图片宽 md:w-75 高 md:h-47;用 items-center 保证垂直居中。=> 浏览器宽一点点、窄一点点,所有尺寸都不变,自然看不出变化。 直到窗口拉到下一个断点阈值,布局一次切换,干净利落。最终代码(最简可读版) #嘉立创PCB#<section className="relative flex items-center justify-center min-h-[400px] md:h-[800px]"> {/* 1. 背景层:固定尺寸 + 居中 */} <div className="absolute inset-0 mx-auto" style={{ maxWidth: 1280, maxHeight: 800, background: 'linear-gradient(180deg,rgba(2,2,2,0) 60%,#020202 99%), url(/unlocking_vast_data_potential.png) 50%/cover no-repeat', }} /> {/* 2. 内容层:限宽 + 居中 + clamp */} <div className="relative z-10 w-full max-w-6xl px-4 text-center"> <h1 className="font-bold text-white text-[clamp(28px,6vw,48px)]"> Unlocking Vast Data Potential </h1> <p className="mt-4 mx-auto max-w-5xl text-[clamp(14px,1.2vw,18px)] text-[#8C8B95]"> LUCI OS is powered by Mavi's video understanding engine … </p> </div> </section> 效果1440px 与 1920px 两档分辨率下,标题、描述、背景图的视觉差异 < 2% ;字号、行宽、图片比例在鼠标拖拽窗口时线性变化,无跳变;移动端仍保持完美自适应,无需额外代码。写在最后把「响应式」做细,核心就是 “在需要的范围内平滑,在不需要的范围内锁死”。 希望这 4 个小技巧也能帮你把“缩放不变形”真正落地。——转载自:CrabXin
让网页在 PC 缩放时“纹丝不动”的 4 个技巧
开源硬件平台
文件下载区在哪?
开源硬件平台
网络变压器可匹配CH318T芯片方案如下 深度解读:CH318芯片与网络变压器的协同逻辑及行业应用启示 一、CH318芯片的核心功能与设计哲学 CH318是WCH(南京沁恒微电子)推出的一款集成化USB信号处理芯片,其设计理念围绕**“隔离、传输、扩展”**三大核心需求展开: 高速隔离:通过电容耦合或网络变压器耦合技术,实现USB信号的电气隔离,解决工业环境中的电磁干扰(EMI)和地环路问题。 距离延长:利用实时中转机制,突破USB 2.0标准下3米传输距离的限制,适用于长距离数据传输场景。 HUB集成:内置USB HUB功能,支持上位机/下位机双模式切换,下行端口兼容高速(480Mbps)、全速(12Mbps)和低速(1.5Mbps)设备,极大简化了系统设计复杂度。 深层逻辑:CH318的纯硬件解决方案(无需驱动)和协议透明性,反映了当前嵌入式系统对低功耗、高集成度、即插即用的迫切需求。其与CH339芯片的搭配方案(如USB转SPI/JTAG)进一步体现了模块化设计的趋势。 二、网络变压器与CH318的匹配关键点 根据资料分析,网络变压器与CH318的匹配需关注以下技术细节: 耦合方式选择:CH318支持电容耦合和网络变压器耦合两种方式。若选择网络变压器: PHY侧驱动类型:需确认CH318的UTP口是电压驱动还是电流驱动(资料未明确说明,需查阅CH318数据手册)。例如,电压驱动型需将变压器中心抽头接3.3V/2.5V/1.8V电源,电流驱动型则需接电容到地。 POE兼容性:若需支持POE供电(如720mA直通电流),应选择PHY侧带3线共模电感的变压器(如铭普H2474CG、HQST H82405SP,H81601S ,H1102NL),这类变压器能更好应对POE受电设备的电流冲击。 阻抗匹配与信号完整性: 网络变压器需实现100Ω差分阻抗匹配(与双绞线特性阻抗一致),避免信号反射。 终端电阻(49.9Ω或50Ω)的并联设计是关键,确保输出端呈现100Ω匹配电阻。 推荐型号参考: 非POE场景:可选用通用型网络变压器(如变压器PHY侧2线共模电感)。 POE场景:优先选择支持720mA以上电流的网络变压器(如普思H6062NL),其三线小环CHOKE设计能增强抗干扰能力。
开源硬件平台
相信我们经常这样写bug(不是 👇: try { const res = await api.getUser() console.log('✅ 用户信息', res) } catch (err) { console.error('❌ 请求失败', err) } 看似没问题每个接口都要 try-catch,太啰嗦了!错误处理逻辑分散,不可控!代码又臭又长💨!💡 目标:不抛异常的安全请求封装我们希望实现这样的调用👇: const [err, data] = await safeRequest(api.getUser(1)) if (err) return showError(err) console.log('✅ 用户信息:', data) 是不是清爽多了?✨ 没有 try-catch,却能同时拿到错误和数据。🧩 实现步骤1️⃣ 先封装 Axios 实例 // src/utils/request.js import axios from 'axios' import { ElMessage } from 'element-plus' const service = axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL, timeout: 10000, }) // 🧱 请求拦截器 service.interceptors.request.use( (config) => { const token = localStorage.getItem('token') if (token) config.headers.Authorization = `Bearer ${token}` return config }, (error) => Promise.reject(error) ) // 🧱 响应拦截器 service.interceptors.response.use( (response) => { const res = response.data if (res.code !== 0) { ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message || '请求失败')) } return res.data }, (error) => { ElMessage.error(error.message || '网络错误') return Promise.reject(error) } ) export default service 拦截器的作用:✅ 统一处理 token;✅ 统一处理错误提示;✅ 保证业务层拿到的永远是“干净的数据”。2️⃣ 封装一个「安全请求函数」 // src/utils/safeRequest.js export async function safeRequest(promise) { try { const data = await promise return [null, data] // ✅ 成功时返回 [null, data] } catch (err) { return [err, null] // ❌ 失败时返回 [err, null] } } 这就是关键! 它让所有 Promise 都变得「温柔」——不再抛出异常,而是返回结构化结果。3️⃣ 封装 API 模块 // src/api/user.js import request from '@/utils/request' export const userApi = { getUser(id) { return request.get(`/user/${id}`) }, updateUser(data) { return request.put('/user', data) }, } 4️⃣ 在业务层优雅调用 <script setup> import { ref, onMounted } from 'vue' import { userApi } from '@/api/user' import { safeRequest } from '@/utils/safeRequest' const user = ref(null) onMounted(async () => { const [err, data] = await safeRequest(userApi.getUser(1)) if (err) return showError(err) console.log('✅ 用户信息:', data) }) </script> 是不是很优雅、数据逻辑清晰、不需要 try-catch、 错误不崩溃。老板说:牛🍺,你小子有点东西​ 插播一则机-会技术大厂,前端-后端-测试,全国均有机-会,感兴趣可以试试。待遇和稳定性都还不错~​🧱 我们还可以进一步优化:实现自动错误提示我们可以给 safeRequest 增加一个选项,让错误自动提示: // src/utils/safeRequest.js import { ElMessage } from 'element-plus' export async function safeRequest(promise, { showError = true } = {}) { try { const data = await promise return [null, data] } catch (err) { if (showError) { ElMessage.error(err.message || '请求失败') } return [err, null] } } 使用时👇: const [err, data] = await safeRequest(userApi.getUser(1), { showError: false }) 这样你可以灵活控制是否弹出错误提示, 比如某些静默请求就可以关闭提示。🧠 进阶:TypeScript 支持(超丝滑)如果你用的是 TypeScript,可以让返回类型更智能👇: export async function safeRequest<T>( promise: Promise<T> ): Promise<[Error | null, T | null]> { try { const data = await promise return [null, data] } catch (err) { return [err as Error, null] } } 调用时: const [err, user] = await safeRequest<User>(userApi.getUser(1)) if (user) console.log(user.name) // ✅ 自动提示类型 老板:写得很好,下次多写点,明天你来当老板——转载自:前端九哥#嘉立创PCB#
我删光了项目里的 try-catch,老板:6
开源硬件平台
家好,我是子昕,一个干了10年的后端开发,现在在AI编程这条路上边冲边摸索,每天都被新技术追着跑。Claude的金主爸爸亚马逊(AWS)偷偷发布了一款AI编程工具,Kiro。我用它做了三个公司的生产级项目需求,深度体验3天后发现:Kiro现在完全免费,可以免费使用Claude-Sonnet-4和Claude-3.7模型规范驱动开发模式,代码质量和工程化程度碾压CursorAgent Hooks自动化系统,真正解决了AI编程工具的健忘问题这可能是今年最值得关注的AI编程工具。下载地址:kiro.dev/Windows用户、Mac用户都可以使用,基于VS Code架构,零学习成本。为什么说Kiro比Cursor更强?技术角度深度分析最近在用真实项目对比各种AI编程工具,发现Cursor在处理复杂业务逻辑时存在几个核心问题:上下文理解不足:经常遗忘项目结构,生成不一致的代码Token优化过度:为了省成本,功能完整性受影响缺乏工程化思维:直接生成代码,缺乏规范和文档Kiro的出现完全解决了这些痛点。Kiro安装体验:零门槛切换Kiro和Cursor一样基于VS Code架构,所以切换成本为零:但在交互设计上,Kiro提供了两种截然不同的工作模式:Vibe模式Spec模式Vibe模式:传统聊天式编程,适合快速原型开发Spec模式:规范驱动开发,这是Kiro的核心创新Spec模式:规范驱动开发的革命这是我见过最接近企业级开发标准的AI工具工作流。Spec模式遵循严格的三阶段开发流程:第一阶段:需求分析(Requirements)自动生成EARS语法标准的需求文档,包含:用户故事定义验收标准边界条件处理非功能性需求第二阶段:系统设计(Design)生成完整的技术设计文档:包含数据库Schema、API接口设计、组件架构图等生产级文档。第三阶段:实现计划(Implementation)将功能分解为有序任务,包含依赖关系和测试要求。任务管理与执行:颗粒度控制Kiro的任务管理机制是其核心优势之一。生成的文档会自动保存在项目根目录的.kiro文件夹中,每个任务都支持独立控制:关键特性:任务状态实时追踪支持并发任务执行智能任务队列管理任务队列这种颗粒度控制完全解决了Cursor一股脑生成代码导致的返工问题。Agent Hooks:自动化质量控制Kiro最具技术含量的功能是Agent Hooks系统,基于文件事件触发自动化检查:实时代码预览预览按钮预览效果通过Follow按钮可以实时查看代码修改,相比Cursor的全量预览和Claude Code的黑盒执行,Kiro提供了更好的可控性。一键回滚机制支持任务级别的原子回滚,比Cursor的checkpoint机制更精确。技术对比:Kiro vs Cursor 实战差异为了客观评估两个工具的差异,我用一个完整的团队任务管理系统项目进行了对比测试:测试场景项目复杂度:类似简化版Jira,包含用户系统、项目管理、任务流转、智能功能、实时通知、数据看板等完整模块技术栈:React + TypeScript + Tailwind CSS + Node.js + Express + PostgreSQL + Prisma ORM + Socket.ioAI集成:调用OpenAI API进行智能工时估算和任务分配评估维度:开发效率、代码质量、文档完整性、可维护性对比结果Cursor表现:直接开始写代码,缺乏整体规划面对复杂业务逻辑时容易遗漏关键模块生成的组件缺乏系统性设计数据库Schema设计不够完整实时通信和AI集成部分需要大量手动调整几乎没有项目文档输出Kiro表现:先生成完整的需求分析和系统设计文档自动分解为用户管理、项目管理、任务系统等独立模块生成完整的数据库Schema和API接口设计包含Socket.io集成和AI功能的详细实现方案自动生成组件架构图和数据流图输出可直接用于团队协作的技术文档核心差异面对这种企业级复杂项目,Cursor更像是功能堆砌,而Kiro展现了真正的系统工程思维。特别是在处理多模块协作、数据库设计、第三方集成等复杂场景时,Kiro的规范驱动开发优势非常明显。插播一则机-会技术大厂,前端-后端-测试,全国均有机-会,感兴趣可以试试。待遇和稳定性都还不错~成本效益分析:定价策略对比当前状态:Kiro完全免费,包含Claude-4模型访问权限未来定价:免费版:50次智能体交互/月Pro版:$19/月,1000次交互Pro+版:$39/月,3000次交互Cursor Pro对比:价格:$20/月限制:500次Chat + 无限Tab补全模型:GPT-4、Claude-4性价比分析: Kiro Pro比Cursor便宜$1,但提供2倍的交互次数,且基于更新的Claude-4模型。技术架构:AWS生态系统优势Kiro基于以下技术栈:前端:Code OSS(VS Code开源版)AI模型:Claude Sonnet 3.7/4.0协议支持:MCP(Model Context Protocol)云基础设施:AWS相比Cursor的多模型策略,Kiro专注于Claude系列模型的深度优化,在代码理解和生成质量上表现更稳定。我的AI编程工具新排名基于深度测试和生产环境使用经验:Kiro - 规范驱动开发,企业级标准Claude Code - 复杂逻辑分析专家Augment - 质量优先,适合高要求项目Cursor - 个人快速原型工具其他工具 - 功能差异明显选择建议适合Kiro的场景:需要完整文档的正式项目团队协作开发对代码质量要求较高企业级应用开发适合Cursor的场景:个人快速原型开发学习编程过程简单功能迭代写在最后Kiro的出现标志着AI编程工具的重要转变:1.0时代:代码生成和补全2.0时代:规范驱动的全流程工程化这种转变反映了行业从能用到好用再到专业的需求升级。建议先用Vibe模式熟悉界面,再尝试Spec模式体验规范驱动开发的完整流程。——转载自:子昕AI编程#技术干货#
有了免费的Kiro,这次真的可以把Cursor扔了!
开源硬件平台
官方文档提到过 ,ref 一把梭,不建议用 reactive。ref - 你的"万能工具箱" // 什么都能装! const name = ref('张三') // ✅ 字符串 const age = ref(18) // ✅ 数字 const isLoading = ref(false) // ✅ 布尔值 const user = ref({name: '李四'}) // ✅ 对象 const list = ref([]) // ✅ 数组 // 用的时候要加 .value name.value = '王五' age.value = 20 reactive - 你的"对象专用盒" javascript 体验AI代码助手 代码解读 复制代码 // 只能装对象! const user = reactive({ // ✅ 对象 name: '张三', age: 18 }) const form = reactive({ // ✅ 对象 username: '', password: '' }) const list = reactive([]) // ✅ 数组(其实也是对象) // 用的时候直接点属性 user.name = '李四' form.username = 'admin' 关键区别:重新赋值问题机-会技术大厂,前端-后端-测试,全国均有机-会,感兴趣可以试试。待遇和稳定性都还不错~场景:从后台请求数据❌ reactive 的错误用法: // 初始化 let list = reactive(['苹果', '香蕉']) // 模拟请求数据 setTimeout(() => { const newData = ['西瓜', '葡萄', '芒果'] // ❌ 错误!这样会丢失响应式! list = newData // 页面不会更新!因为 list 的"监听器"断了 }, 1000) ✅ ref 的正确用法: // 初始化 const list = ref(['苹果', '香蕉']) // 模拟请求数据 setTimeout(() => { const newData = ['西瓜', '葡萄', '芒果'] // ✅ 正确!通过 .value 重新赋值 list.value = newData // 页面正常更新! }, 1000) ✅ reactive 的正确用法(如果非要用): const state = reactive({ list: ['苹果', '香蕉'] }) setTimeout(() => { const newData = ['西瓜', '葡萄', '芒果'] // ✅ 正确!只改属性,不改对象本身 state.list = newData }, 1000) 📝 实战选择指南情况1:基础数据 → 必须用 ref // ✅ 用 ref const count = ref(0) const name = ref('') const isVisible = ref(true) // ❌ reactive 会报错! // const count = reactive(0) // 报错! 情况2:需要重新赋值 → 必须用 ref // 从API获取数据 const data = ref(null) const fetchData = async () => { const result = await api.getData() data.value = result // ✅ 可以重新赋值 } // 切换页面数据 const currentPageData = ref([]) const changePage = (page) => { currentPageData.value = getDataByPage(page) // ✅ 可以重新赋值 } 情况3:固定对象,只改属性 → 可以用 reactive // 表单数据 - 通常不会整个替换 const form = reactive({ username: '', password: '', remember: false }) // 用户信息 - 通常不会整个替换 const userInfo = reactive({ name: '张三', age: 25, avatar: '' }) 情况4:不确定用哪个 → 无脑用 ref // 安全第一! const something = ref(初始值) 🎯 黄金法则处理数字、字符串、布尔值? → 用 ref需要 xxx = 新数据 这样赋值? → 用 ref只是一个固定对象,只改里面的属性? → 可以考虑 reactive不确定? → 直接用 ref记住:ref 永远不会错,reactive 有时候会坑你!——转载自:我是天龙_绍#技术干货#
什么时候用ref,什么时候用reactive?
开源硬件平台
在公司干了几年,带个小团队,零零总总也面试了上百个前端候选人了。说实话,有时候面完一天,感觉人都是麻的。最让我头疼的是什么?就是“算法题”这个环节。我经常遇到两种候选人。一种是一听算法题,就两手一摊,表情痛苦,说“哥,我天天写业务,真没准备这个”。另一种呢,正好相反,题目一出,眼睛一亮,不出三十秒,就把LeetCode上背得滚瓜烂熟的最优解,一字不差地敲了出来,然后一脸期待地看着我。说实话,这两种,都不是我最想看到的。这就引出了一个很多候选人都想问,但不敢问的问题:“你们这些面试官,到底怎么想的?你们明知道我们前端平时工作中,99%的时间都用不上这些,为什么非要折磨我们?”今天,我就想站在桌子对面,跟大伙掏心窝子地聊聊,我们问算法题,到底图个啥。首先,我得承认一件事:我们知道你工作中不怎么写算法对,你没看错。我心里门儿清,我团队里的小伙伴们,每天的工作是跟产品经理“吵架”,是跟UI设计师对像素,是封装React/Vue组件,是处理浏览器兼容性,是调CSS。我招你进来,也不是为了让你用动态规划来给按钮加border-radius的。我们不会天真地以为,前端开发就是算法竞赛。如果你能把一个复杂的业务表单组件写得清晰、可维护、可扩展,在我眼里,这远比你徒手写一个红黑树要来得有价值。所以,请你先放轻松。我们不是在考察你是不是一个“算法大神”。机-会技术大厂,前端-后端-测试,全国均有机-会,感兴趣可以试试。待遇和稳定性都还不错~那我们到底在看什么?——思路远比答案重要既然不是看你会不会背最优解,那我们花这宝贵的20分钟,到底在考察什么?其实,算法题只是一个“载体”,一个“媒介”。通过这个载体,我想看到的是这几样东西:1. 你是怎么“解读”问题的(沟通与理解能力)一个靠谱的工程师,拿到需求不会立刻动手。他会先问问题,搞清楚所有的边界和约束。我出一道题:“写个函数,找出数组中第二大的数。”普通候选人:埋头就开始写代码。我欣赏的候选人:会先问我,“这个数组里会有重复的数字吗?会是无序的吗?会有负数吗?如果数组长度小于2怎么办?”你看,这就是差距。我能通过这些问题,看出你是否严谨,是否有处理边界情况的意识。这个能力,在你将来面对产品经理那些模糊的需求时,至关重要。2. 你的“思路”是否清晰(逻辑思维)我最喜欢看到的,不是你直接写出最优解,而是你告诉我你的思考过程。比如,你可以说:“我首先想到的,是一个最笨的办法,先排序,然后取倒数第二个。这个时间复杂度是O(n log n)。但感觉可以优化,我再想想……也许我只需要遍历一遍,用两个变量来维护最大值和第二大值,这样时间复杂度就降到O(n)了。”这个“先暴力,再优化”的思考过程,在我看来,比你直接默写出最优解要加分得多。因为它展示了你的逻辑推理能力和优化意识。3. 你的代码“品味”(工程素养)算法题的代码量不大,但足以管中窥豹,看出一个人的代码“品味”。你的变量是怎么命名的?a, b, c 还是 max, secondMax, current?你有没有处理我刚才提到的那些边界情况?你的代码有没有基本的缩进和格式?这些细节,都反映了你平时的编码习惯。一个连算法题都写得乱七八糟的人,我很难相信他在业务项目里能写出整洁的代码。4. 当你卡住时,你会怎么办?(抗压与学习能力)我有时候会故意出一些有点难度的题。我不是为了让你难堪,而是想看看你卡住的时候,会有什么反应。是直接放弃,说“不会”?还是会尝试跟我沟通,说“我卡在xxx了,能不能给点提示?”我非常乐意给提示。我更想招一个能和我一起“协作”解决问题的人,而不是一个遇到困难就“躺平”的人。你面对一道题的态度,很可能就是你未来面对一个技术难题的态度。给求职者的一些真心话所以,聊了这么多:别光背题,没用。 我只要稍微改动一下题目条件,或者问你为什么这么写,背题的同学马上就露馅了。多练习“说” 。刷题的时候,试着把你的思路说出来,录下来自己听听,或者讲给朋友听。面试时的口头表达,和自己闷头做题是两回事。重点理解“为什么” 。不要满足于“这道题这么解”,要去理解它为什么要用双指针,为什么要用哈希表。理解了思路,才能举一反三。面试时,心态放平。 没做出最优解,真没关系。把你思考的过程、你的尝试、你的权衡都清晰地表达出来,你已经赢了很多人了。我知道,让前端去卷算法,这个“游戏规则”本身就不那么公平。我们想找的是一个会思考、会沟通、有工程素养的“解决问题的人”。算法题,只是恰好成了当前最方便、成本最低的考察工具而已。——转载自:ErpanOmer
前端真的需要懂算法吗?聊聊感受
开源硬件平台
优质硬件创作分享平台
打赏记录
服务时间:周一至周六 9::00-18:00 · 联系地址:中国·深圳(福田区商报路奥林匹克大厦27楼) · 媒体沟通:pr@jlc.com · 集团介绍
移动社区