1. 免费IP定位服务的限制与挑战

IP定位技术广泛应用于广告投放、用户行为分析、安全监控等领域,然而,大多数免费IP定位工具存在诸多限制。

1.1 精度问题

免费IP定位服务通常依赖于公开的数据源,这些数据往往不如付费服务精准。免费工具的定位精度往往只能精确到国家或省级地区,无法提供更精确的城市或街道级别的定位信息。因此,许多依赖高精度地理信息的场景(如精准营销、金融风险控制等)不适合使用免费工具。

1.2 数据更新频率

免费服务的数据更新频率较低,无法及时反映IP地址的变化。由于IP地址的归属地和运营商信息是动态变化的,特别是在网络环境较为复杂的地区,更新缓慢的数据库可能导致查询结果不准确,从而影响业务决策。

1.3 服务限制

免费工具通常有查询次数限制。例如,一些免费服务每天只能提供几十次查询,而对于需要高频次查询的业务,这显然无法满足需求。免费服务还可能限制某些功能,如无法获取运营商信息、ASN编号等详细数据,严重影响其应用场景的拓展。

1.4 应用场景的局限性

虽然免费的IP定位工具可以应付一些基本的应用需求,如简单的用户地域定位和基本的数据分析,但它们并不适用于那些对精度要求高的场景。例如,在广告投放、金融风控等领域,定位误差可能导致严重的经济损失,因此对于这些高精度需求的场景,免费工具无法满足需求。

2. 付费IP定位服务的优势

付费IP定位服务通常能提供更高的精度和更丰富的数据,适用于高要求的商业场景。

2.1 高精度定位

付费服务能够提供更加精准的IP定位,精确到城市甚至街道级别。在某些高精度需求场景下,付费服务能够提供详细的IP地址归属地,甚至能显示运营商信息、ASN编号以及用户的地理坐标(经纬度)。这一点对精准营销、反欺诈监控、跨区域服务定制等应用至关重要。

2.2 更丰富的数据维度

除了基本的地理位置,付费IP定位服务通常还提供更丰富的附加数据。例如,IP的风险评分、代理检测、历史位置记录、用户行为分析等,这些都能帮助企业更加全面地评估IP地址的可靠性与风险。

2.3 实时更新和监控

与免费服务相比,付费服务的数据更新频率更高,能够实时监控IP地址的变化。这对于需要快速响应的业务(如金融反欺诈、风险控制等)至关重要。付费服务通常会提供更稳定、持续的数据支持,确保企业在面对突发事件时能够快速调整策略。

2.4 API和集成支持

大多数付费IP定位服务提供API接口,企业可以通过API将IP定位服务集成到现有系统中,支持大规模、自动化的数据获取。这对于开发者和企业来说,能够提高工作效率,降低运营成本。
免费IP定位和付费服务的精度差距有多大?

3. 精度差距的实例对比

通过实际案例对比,我们可以更清晰地看到免费和付费服务在精度上的差距。

3.1 归属地对比

为了更清晰地对比不同之处,我们选择了IP数据云的免费查询和付费查询进行了比较。当我们查询一个IP地址时,通过免费的IP定位服务,查询结果可能仅显示该IP所属的国家和省份;而通过付费服务,除了国家和省份信息,还可以精准到具体的城市/街道,并附带运营商信息、经纬度、风险评分等。
IP数据云免费与付费查询结果对比

3.2 应用场景差异

以金融行业为例,银行或支付平台需要对用户进行身份验证和风险评估。在这个过程中,IP定位的精度至关重要。免费的IP定位服务可能无法准确判断用户的真实地理位置,这可能导致跨区域交易的误判。而付费服务能够提供更精确的位置信息,帮助企业更好地识别潜在的风险和欺诈行为。

4. 如何选择适合的IP定位服务

根据不同的业务需求,选择合适的IP定位服务是至关重要的。

4.1 业务需求驱动

对于一些中小型企业,免费服务足以应付一些简单的地理定位需求。而对于大型企业或对精度有较高要求的场景(如广告投放、精准营销、风险控制等),付费服务则显得更为必要。

4.2 成本效益分析

免费服务通常适用于预算有限或对精度要求不高的场景。但当业务规模扩大,或者需要处理更多的数据和复杂的需求时,选择付费服务能够提供更高的ROI。企业应根据自身的预算和业务需求做出决策。

5. 技术和安全性上的差异

5.1 技术实力

付费服务背后通常拥有更多的技术支持,提供更加稳定和高效的服务。技术团队的持续研发和优化,能够保证付费服务始终处于技术前沿。

5.2 安全性和隐私保护

对于需要保护用户隐私和数据安全的应用场景,付费服务通常会提供更加严密的数据加密、IP匿名化等安全措施。付费服务不仅保障数据的安全,还能避免数据滥用,帮助企业减少法律风险。

6. IP定位服务的选择

在选择IP定位服务时,企业应根据实际需求来决定。如果业务需求较为简单,且对精度的要求不高,那么免费服务是一个不错的选择。但对于大中型企业,尤其是金融、广告、电子商务等行业,精确的IP定位与实时数据支持是至关重要的。在这些场景下,IP数据云作为付费服务提供了精准的定位结果和丰富的附加功能,帮助企业更好地实现精准营销和风控监控。通过对比,我们可以看到IP数据云在提供高精度IP定位数据的同时,能够为企业带来更多的功能支持,尤其适用于那些对数据安全、精度、更新频率有高要求的业务场景。

最近看到飞牛事件,开始认真审视自己对外发布服务的安全性,想向大家请教一些相对成熟、可落地的 Web / WAF 方案。

当前现状

  • 通过 Lucky 作为反向代理对外发布应用
  • 对外暴露面较小,主要是自建服务( NAS / Web 等)

期望能力

  1. 支持 SSL 证书自动申请与续期( ACME / Let’s Encrypt ,有尝试过 NPM 或者 cerd ,家庭缺少部分端口,似乎不太好用,也可以大佬分享下)
  2. 具备 可用的 WAF 规则集
  3. 偏向 自建 / 私有化部署 / 开源

已完成的测试

雷池( SafeLine )

  • 整体体验不错,拦截能力和规则集都比较成熟
  • 但日志、分析等关键能力基本在 Pro 版本
  • 对个人 / 自建环境来说 pro 成本偏高,最终放弃

南墙( OpenWAF )

  • 能用,部署和使用相对轻量
  • 可控性略弱 ,毕竟不是专业的从业人员。
  • 日常防护可以,但整体不够“顺手”

想请教大家

  • 是否有更合适的 Web / WAF 方案推荐?
  • 是否有实际长期运行的经验分享(误报率、维护成本、性能等)?
  • 如果是「反向代理 + WAF + 自动证书」这一套,大家目前都怎么组合?

感谢分享 🙏

这网站登录要验证码,我想一直保持登录,就准备定时去请求后端服务保持登录态,结果没注意到它有签名。

看了一下其实签名很简单。
image
先看了下个人信息部分,后端返回加密的,前端解开了,先验证下在哪里脱敏的,有的系统是后端脱敏,有的偷懒就在前端脱敏。

既然解密了邮箱,先搜一下 decrypt 看看
image
找到了几个解密方法,直接去 app......js 里面看
image
这里是加解密方法,下面有两个密钥,其实可以猜一下,长的是私钥(别问我为什么)

然后验证下
image
成功解析了,是一个私钥(为什么不用 AES 呢?这样不就是后端用公钥加密,前端用私钥解密了)

image
解密成功,果然是前端脱敏的。

下面看看请求签名吧。
image
每个 api 的请求都有个 signature 的请求头
这个签名由两部分组成,其实见得多了就知道,这里就是时间戳+MD5

我们先搜索 signature
image
直接锁定了,定位过去打断点就行了。

image
下断点,触发请求,这里主要看Object(h.a)(o, n)

image
第一部分断点下错了,应该在 app 里面下,不影响,现在已经断到了

image
这里就是 a+;+o,a 是时间戳跟上面的猜测是一样的,o 是 Object(f.a)(a, n)的结果,n 就是请求体,直接单步进去

image
这里就是核心方法了,其实很简单,自己分析或者直接下断点就行了
r 就是 md5
无非就是i = e + "," + a + ",1e31af8c14999aa99d78537a8641ea4d"或者c = e + ",1e31af8c14999aa99d78537a8641ea4d"

image
1770360125648,10,1,1e31af8c14999aa99d78537a8641ea4d
时间戳+请求体中 json 的键值对的值+固定字符串

image
1770360125648,10,1,1e31af8c14999aa99d78537a8641ea4d的 md5 结果为:20736f5e42b82db8c5d0c92bdd89c262

image
后端请求的签名和我们拿得原文再 MD5 的签名一模一样,这里报错是因为断点时间太长导致请求的时间戳超时,实际上算法是对的。

原文链接:https://tecdat.cn/?p=44948
原文出处:拓端抖音号@拓端tecdat

封面

引言

2025年,全球半导体产业正站在技术革新与供应链重构的关键十字路口。AI大模型的爆发式增长,让高端算力芯片、高带宽存储(HBM)成为需求核心,直接推动光刻机、先进封装、光刻胶等关键环节的技术迭代进入“加速档”;而地缘政治博弈与“科技自立自强”的国家战略双重驱动下,国产化替代已从“可选”变为“必选”,成为中国半导体产业突围的核心命题。从晶圆制造到封装测试,从设备材料到终端应用,产业各环节正经历前所未有的变革,机遇与挑战并存。

本报告洞察系统梳理产业核心趋势、关键数据与落地路径。本文完整报告数据图表和文末100+最新参考报告合集已分享在交流群,阅读原文查看、进群咨询,定制数据、报告和800+行业人士共同交流和成长。

一、产业核心趋势:AI与国产化双轮驱动

半导体产业的增长引擎已从传统消费电子彻底转向AI算力与国产化替代。全球半导体市场2025年预计突破6970亿美元,其中AI相关逻辑芯片、GPGPU增速分别达16.8%和27%,成为最强增长动力;而中国作为全球最大半导体市场,2024年贡献ASML 41%的营收,却在高端光刻机、先进光刻胶等领域国产化率不足1%,千亿级替代空间已全面打开。

(一)光刻机:高端垄断与国产突破的正面博弈

光刻机作为半导体制造的“皇冠明珠”,是国产化替代的核心攻坚环节。2024年全球市场呈现“一超两强”格局,ASML以61.2%的份额主导全局,尤其在EUV和ArFi先进机型中形成绝对垄断,Canon与Nikon则聚焦成熟制程。

2024年全球光刻机厂商出货量份额横向条形图表1
2024年全球光刻机厂商出货量份额(百分比):ASML 61.2%、Canon 34.1%、Nikon 4.7%、其他0.0%。
3秒解读:ASML垄断高端市场,国产厂商尚未进入主流份额,成熟制程是国产替代首攻方向。
对应人群行动建议:晶圆厂可优先布局ASML成熟制程设备备份,降低断供风险;国产设备厂商应聚焦DUV细分环节(如双工件台、光源系统)突破,联合晶圆厂开展联合验证,缩短导入周期。
2024年全球光刻机市场份额 - 保持横向比例条形图1数据EXCEL及图表PDF模板已分享到会员群
中国光刻机国产化正迎来关键突破:上海微电子90nm ArF光刻机实现出货,华卓精科双工件台打破国外垄断,哈尔滨工业大学成功研制13.5nm EUV光源,为7nm以下先进制程奠定基础。但当前仍面临验证周期长、核心零部件依赖进口等挑战,短期聚焦成熟制程替代、长期攻坚EUV核心技术,成为行业共识。

(二)光刻胶:国产化率的“技术阶梯”困境

光刻胶作为光刻工艺的核心材料,其国产化进程呈现明显的技术梯度差异——技术难度越高,国产化率越低,成为制约先进制程推进的关键瓶颈。

PCB光刻胶国产化率瀑布图表7
PCB光刻胶国产化率(百分比):干膜光刻胶5%、湿膜光刻胶50%、阻焊油墨50%、整体国产化率35%。
3秒解读:中低端产品已实现部分替代,干膜光刻胶因技术壁垒高,仍高度依赖进口。
对应人群行动建议:材料厂商可优先加大湿膜光刻胶产能扩张,巩固现有替代成果;同时联合PCB厂商开展干膜光刻胶联合研发,聚焦光引发剂等核心配方突破;晶圆厂可建立国产材料测试绿色通道,缩短验证周期。
PCB光刻胶国产化率瀑布图表7数据EXCEL及图表PDF模板已分享到会员群

半导体光刻胶国产化率阴影条形图表8
半导体光刻胶国产化率(百分比):G/I线光刻胶30%、KrF光刻胶5%、ArF光刻胶0.5%、EUV光刻胶0%。
3秒解读:先进制程光刻胶完全依赖进口,7nm以下制程面临供应链安全风险。
对应人群行动建议:政策层面可加大对EUV光刻胶研发的专项补贴,支持校企联合攻关;企业层面应加强与晶圆厂的工艺协同,针对14nm制程所需的KrF光刻胶开展量产验证,逐步突破技术瓶颈。
半导体光刻胶国产化率阴影条形图表8数据EXCEL及图表PDF模板已分享到会员群

(三)先进封装:后摩尔时代的性能“破局者”

随着制程微缩逼近物理极限,先进封装成为AI时代提升芯片性能的核心路径——通过Chiplet异构集成、2.5D/3D堆叠等技术,无需制程迭代即可实现算力翻倍,成为产业增长的新引擎。

2019-2029年全球先进封装技术路线占比堆叠面积图表10
2019-2029年全球先进封装技术路线占比:2.5D封装占比从30%升至55%,3D封装从20%升至42%,其他先进封装从50%降至3%。
3秒解读:2.5D/3D封装成为主流,AI芯片需求直接推动技术迭代提速。
对应人群行动建议:封装厂商应重点布局CoWoS、Chiplet技术,加大与HBM厂商的协同研发;AI企业在芯片设计阶段即融入先进封装方案,优化算力密度与功耗平衡;设备厂商需聚焦TSV刻蚀、微凸块电镀等关键设备突破,适配封装技术升级需求。
全球先进封装技术占比堆叠面积图表10数据EXCEL及图表PDF模板已分享到会员群
中国先进封装产业呈现“成熟制程与先进封装齐头并进”的格局:长电科技XDFOI Chiplet工艺进入稳定量产,通富微电承接AMD 70%-80%的封测订单,华天科技布局面板级封装(FOPLP),本土企业已在AI芯片封测领域形成差异化竞争力。


相关文章

2025半导体行业核心趋势与市场动态报告:AI驱动、先进封装、SiC、掩膜版|附130+份报告PDF、数据、可视化模板汇总下载

原文链接:https://tecdat.cn/?p=44426


二、关键支撑环节:设备、材料与供应链的协同突围

(一)半导体设备:市场增长与国产替代的共振效应

全球半导体设备市场正受益于AI驱动的扩产潮,2025年预计达1210亿美元,2026年增至1390亿美元,其中晶圆加工设备(WFE)占比超80%。中国作为全球最大设备采购市场,2024年设备采购金额达490亿美元,国产化率已提升至13.6%,刻蚀、清洗设备进展显著。

全球半导体设备销售额气泡图表2
全球半导体设备销售额(亿美元):2023年1063、2024年1171、2025年预测1215、2026年预测1394,增长率分别为10.2%、3.8%、14.7%。
3秒解读:设备市场稳步增长,2026年将迎来加速期,AI芯片扩产是核心驱动力。
对应人群行动建议:设备厂商应聚焦客户验证周期缩短,针对晶圆厂需求优化设备稳定性;晶圆厂可加大国产设备导入比例,采用“成熟制程批量导入+先进制程小批量测试”的策略,降低替代风险。
全球半导体设备销售额气泡图表2数据EXCEL及图表PDF模板已分享到会员群

(二)混合键合:AI芯片互连的“核心纽带”

混合键合技术通过铜-铜直接键合实现10μm以下间距互连,是HBM和3D集成的关键支撑,2030年前市场规模年复合增长率达24.7%。当前全球市场由BESI主导,占比67%,国产厂商如拓荆科技已推出量产设备,在AI驱动下国产化进程加速。

混合键合技术多维评估雷达图表5
混合键合技术多维评估(0-30分):市场规模6.2、年复合增长率24.7、技术成熟度8.0、国产化率2.0、AI需求拉动9.0。
3秒解读:技术需求旺盛,但国产化率偏低,存在较大替代空间。
对应人群行动建议:企业应加强与HBM厂商的联合研发,聚焦设备精度与可靠性提升;政策层面可支持核心零部件国产化,降低设备制造成本;产业链应建立技术标准联盟,加速国产设备验证流程。
混合键合技术评估雷达图表5数据EXCEL及图表PDF模板已分享到会员群

2023年全球混合键合设备厂商市场份额半圆面积图表6
2023年全球混合键合设备厂商市场份额:BESI 67%、其他厂商33%。
3秒解读:BESI垄断全球市场,国产厂商需突破技术瓶颈实现弯道超车。
对应人群行动建议:国产设备厂商应聚焦客户验证,针对AI芯片互连需求优化设备性能;晶圆厂可给予国产设备更多测试机会,通过联合攻关解决实际应用中的技术问题。
混合键合设备市场份额半圆面积图表6数据EXCEL及图表PDF模板已分享到会员群

(三)锡供应:电子焊料的地缘风险预警

锡作为半导体封装的关键材料,其供应稳定性直接影响封装环节产能。2024年全球锡产量高度集中,中国、印尼、缅甸三国占比超50%,供应易受政策和地缘冲突影响,而AI芯片封装密度提升进一步推动锡需求增长,供应链稳定性成为企业关注重点。

2024年全球锡产量分布气泡图表9
2024年全球锡产量(万吨):中国6.9、印尼5.0、缅甸3.4、其他地区14.7。
3秒解读:供应集中度高,地缘风险可能引发价格波动,影响封装成本。
对应人群行动建议:企业应建立多区域供应商体系,降低单一地区依赖;布局再生锡回收业务,提升资源循环利用效率;密切关注地缘政治动态,建立库存预警机制。
全球锡产量分布气泡图表9数据EXCEL及图表PDF模板已分享到会员群

(四)测试设备:AI芯片复杂度驱动的需求爆发

AI芯片测试向量深度指数级膨胀,推动测试设备量价齐升——2025年全球测试设备市场预计同比增长48.1%,达166亿美元。中国测试设备市场中,测试机占比62.3%,但SoC测试机国产化率仅10%,高端替代空间广阔。

2024年中国半导体测试设备细分市场占比华夫图表3
2024年中国半导体测试设备细分市场占比(每格代表1%):测试机62.3%、探针台20.0%、分选机17.7%、其他0.0%。
3秒解读:测试机是核心细分领域,国产化潜力巨大,是测试设备替代的核心突破口。
对应人群行动建议:测试设备厂商应聚焦AI芯片专用测试方案,开发高算力、高精度测试设备;晶圆厂可导入国产测试设备进行并行验证,逐步提高国产设备在测试环节的占比。
中国测试设备市场结构华夫图表3数据EXCEL及图表PDF模板已分享到会员群

全球半导体测试设备销售额及同比增速双轴图表4
全球半导体测试设备销售额(亿美元):2024年112、2025年预测166、2026年预测186、2027年预测199,增长率分别为48.1%、12.0%、7.0%。
3秒解读:测试设备市场进入高速增长期,2025年增速最快,AI芯片是核心驱动因素。
对应人群行动建议:企业应加大研发投入,突破高端测试机核心技术,尤其是SoC测试机的国产化;产业链应建立测试设备与芯片设计的协同机制,提升测试效率。
全球测试设备销售额双轴图表4数据EXCEL及图表PDF模板已分享到会员群

三、核心数据对比与落地路径

(一)不同报告数据差异对比表

核心主题报告1:华创证券《光刻机行业深度研究报告》报告2:亿欧智库《2025年泛半导体光刻胶供应链发展研究》报告3:浙商证券《2026年半导体设备行业策略报告》数据差异原因分析
全球半导体设备市场规模2025年1210亿美元无直接数据2025年1215亿美元5亿美元差异统计口径不同,是否包含二手设备及配件
光刻胶国产化率半导体光刻胶国产化率不足1%G/I线30%、KrF5%、ArF0.5%无直接数据细分品类差异报告1为整体口径,报告2按技术路线细分
先进封装市场规模2029年695亿美元无直接数据2029年600亿美元95亿美元差异预测时间周期及技术路线统计范围不同

(二)可落地的3件事

  1. 晶圆厂联合材料厂商建立国产光刻胶联合测试平台,优先导入KrF光刻胶进行量产验证,制定明确的验证标准与时间表,缩短替代周期;
  2. 封装企业聚焦Chiplet与CoWoS技术,与AI芯片设计公司共建联合实验室,同步优化封装方案与芯片设计,提升产品适配性;
  3. 设备厂商联合高校、科研院所攻坚EUV光源、双工件台等关键环节,建立核心零部件国产化供应链,降低对外依赖。

(三)风险提示与应对方案

风险类型具体风险应对方案社群支持
技术风险先进制程设备研发进度不及预期聚焦成熟制程替代,分阶段攻坚核心技术,优先满足中低端市场需求共享最新技术研发进展与专利布局,提供技术交流对接
供应链风险高端零部件进口受限建立多区域供应商体系,扶持国产零部件企业,签订长期供货协议提供国产零部件厂商名录与对接机会,组织供应链对接会
市场风险全球晶圆厂扩产放缓拓展汽车电子、工业控制等细分市场,开发定制化设备与材料分享细分市场需求数据与客户资源,提供市场趋势研判

四、核心数据表格汇总

(一)全球半导体核心市场规模预测(亿美元)

领域2025年预测2026年预测年增长率
全球半导体市场6971.84760711.2%
全球晶圆代工市场170020%
全球半导体设备市场1210139014.9%
全球先进封装市场11%(2023-2029CAGR)
全球测试设备市场16618612.0%

(二)中国半导体核心产品国产化率(%)

产品类型国产化率关键企业
光刻机不足1%上海微电子、华卓精科
PCB光刻胶35%容大感光、广信材料
半导体光刻胶(G/I线)30%晶瑞电材、彤程新材
半导体光刻胶(KrF)5%彤程新材、晶瑞电材
半导体设备13.6%北方华创、中微公司
先进封装未明确长电科技、通富微电

五、数据图表列表

  1. 2024年全球光刻机厂商出货量份额横向条形图表1
  2. 全球半导体设备销售额气泡图表2
  3. 2024年中国半导体测试设备细分市场占比华夫图表3
  4. 全球半导体测试设备销售额及同比增速双轴图表4
  5. 混合键合技术多维评估雷达图表5
  6. 2023年全球混合键合设备厂商市场份额半圆面积图表6
  7. PCB光刻胶国产化率瀑布图表7
  8. 半导体光刻胶国产化率阴影条形图表8
  9. 2024年全球锡产量分布气泡图表9
  10. 2019-2029年全球先进封装技术路线占比堆叠面积图表10

封面

本专题内的参考报告(PDF)目录

  • 半导体行业分析手册之二:混合键合设备:AI算力时代的芯片互连革命与BESI的领航之路.pdf
  • 2026-02-03 16:15
  • 半导体行业深度报告:Agentic AI时代的算力重构:CPU,从“旁观者”到“总指挥”的价值回归.pdf
  • 2026-02-03 16:15
  • 半导体行业先进封装与测试专题报告:先进封装量价齐升,测试设备景气上行.pdf
  • 2026-02-03 16:14
  • 半导体行业分析手册之二:混合键合设备,AI算力时代的芯片互连革命与BESI的领航之路.pdf
  • 2026-01-30 15:55
  • 锡专题:供应扰动频繁,AI+半导体催化需求增长.pdf
  • 2026-01-27 15:47
  • 半导体先进封装研究报告.pdf
  • 2026-01-26 13:49
  • 半导体测试设备行业深度研究报告:算力迭代与先进封装重塑价值,国产测试设备步入替代加速期.pdf
  • 2026-01-26 13:49
  • 2026年半导体设备行业策略报告:AI驱动新成长,自主可控大时代.pdf
  • 2026-01-26 13:48
  • 对点咨询&韬略咨询:2025半导体行业薪酬报告.pdf
  • 2026-01-23 15:42
  • 江苏省市场监督管理局:2025内外贸一体化认证服务指南-半导体产业.pdf
  • 2026-01-19 16:52
  • CSA Research:2025年半导体照明产业发展蓝皮书.pdf
  • 2026-01-16 15:08
  • 【人才】猎聘2025半导体产业人才供需洞察报告.pdf
  • 2026-01-13 17:24
  • 爱建电子深度报告:半导体产业的发展复盘与方向探索.pdf
  • 2025-12-30 14:40
  • 2025深圳市半导体与集成电路行业中小企业数字化转型实践样本.pdf
  • 2025-12-22 15:13
  • 2025 半导体业人才报告书.pdf
  • 2025-12-17 16:10
  • 2025年中国半导体设备特殊涂层零部件行业独立市场研究报告.pdf
  • 2025-12-09 16:14
  • 2025年泛半导体光刻胶供应链发展研究.pdf
  • 2025-12-05 16:47
  • 亿欧智库 _ 2025年泛半导体光刻胶供应链发展研究.pdf
  • 2025-12-04 16:55
  • 集微网:2025中国半导体激光设备白皮书.pdf
  • 2025-11-24 15:08
  • 云半导体:需求“全球”强劲至2026年.pdf
  • 2025-10-21 16:53
  • 光刻机行业深度研究报告:光刻机,半导体设备价值之冠,国产替代迎来奇点时刻.pdf
  • 2025-10-18 17:10
  • 2025年全球及中国半导体制造市场预测和产业分析报告.pdf
  • 2025-10-17 16:05
  • 深芯盟:2024年年国产半导体前道设备调研报告.pdf
  • 2025-10-17 16:03
  • 2025年深圳集成电路及国产半导体产业调研报告.pdf
  • 2025-10-17 16:02
  • 2025年国产半导体设备及深圳集成电路产业调研报告.pdf
  • 2025-10-17 16:02
  • 2024年深芯盟国产半导体前道设备+第三代半导体(SiC)设备调研分析报告.pdf
  • 2025-10-17 15:58
  • 光刻机行业深度研究报告:半导体设备价值之冠,国产替代迎来奇点时刻.pdf
  • 2025-10-17 15:51
  • MIR睿工业:2025年上半年中国半导体行业投融资情况分析报告.pdf
  • 2025-10-11 16:01
  • 半导体行业专题:空白掩模版:光刻工艺核心原料,国产化亟待突破.pdf
  • 2025-10-11 15:51
  • 半导体行业专题研究:AI存储革命已至,“以存代算”开启存储新纪元.pdf
  • 2025-09-30 16:36
  • 蓝凌研究院:2025年半导体企业AI数智化白皮书.pdf
  • 2025-09-24 16:28
  • 半导体设备行业深度:AI芯片快速发展,看好国产算力带动后道测试&先进封装设备需求.pdf
  • 2025-09-23 16:35
  • 2025第三代半导体行业研究报告.pdf
  • 2025-09-21 17:17
  • 美光(Micron):2025年半导体制造工艺介绍报告(英文版).pdf
  • 2025-09-19 16:44
  • 2025年第37期(总第712期):2025年美国半导体产业现状.pdf
  • 2025-09-12 16:39
  • 半导体行业分析手册系列之一:AI驱动下的晶圆代工新纪元,2025产业格局、技术突破与中国力量.pdf
  • 2025-08-29 16:23
  • 半导体存储行业深度研究报告:供需双振驱动价格持续上扬,企业级存储国产化加速推进.pdf
  • 2025-08-28 16:31
  • 半导体系列深度报告:走向更高端,国产掩膜版厂商2.0时代开启.pdf
  • 2025-08-22 16:25
  • 半导体行业深度报告:高端先进封装:AI时代关键基座,重视自主可控趋势下的投资机会.pdf
  • 2025-08-16 16:42
  • 埃森哲:2025年应对半导体行业的的人才短缺报告.pdf
  • 2025-08-10 18:39
  • 2025年弥合鸿沟:全球半导体行业人才短缺应对路径研究报告(英文版).pdf
  • 2025-08-06 16:16
  • 薪智:2025年Q3薪智半导体行业薪酬报告.pdf
  • 2025-07-27 17:23
  • 可控核聚变行业专题:核聚变“黑马”FRC,关注半导体开关产业趋势.pdf
  • 2025-07-25 15:42
  • 深圳来觅数据信息科技-半导体2025年二季度投融市场报告.pdf
  • 2025-07-19 19:37
  • 2025年全球半导体产业展望报告:AI赋能增长(英文版).pdf
  • 2025-07-10 16:41
  • 半导体行业专题研究:涨价持续性+AI强催化+国产化加速,重点推荐存储板块机遇.pdf
  • 2025-07-04 16:19
  • 半导体行业2025年中期策略报告:“AI+国产化”双轮驱动,并购整合浪潮已掀起.pdf
  • 2025-06-30 15:03
  • 半导体材料系列报告之一:国际形式严峻,国产半导体材料行业如何发展.pdf
  • 2025-06-27 16:31
  • 2025年第三代半导体SiC GaN产业链研究报告-深企投.pdf
  • 2025-06-21 17:19
  • 电子行业2025年中期投资策略:人工智能创新百花齐放,半导体自主可控加速推进.pdf
  • 2025-06-21 17:14
  • 2025第三代半导体产业链研究报告.pdf
  • 2025-06-20 15:06
  • 沙利文:2025年中国半导体及光伏用石英坩埚行业市场独立研究报告.pdf
  • 2025-06-19 16:13
  • 半导体产业人才报告-智联猎头.pdf
  • 2025-06-16 09:46
  • 与非网:2024年车规功率半导体产业分析报告.pdf
  • 2025-06-12 15:36
  • 2025全球半導體產業大調查-毕马威_Password_Removed.pdf
  • 2025-06-09 13:37
  • 2025深入了解博世的碳化硅(SiC)半导体技术白皮书.pdf
  • 2025-06-04 16:27
  • 2025深入了解博世的碳化硅(SiC)半导体技术白皮书(英文版).pdf
  • 2025-06-04 16:27
  • 金元证券:功率半导体黄金赛道:技术迭代×能源革命×国产替代的三重奏.pdf
  • 2025-05-30 17:01
  • 意法半导体:2025年电机驱动IC工业应用选型指南白皮书.pdf
  • 2025-05-25 16:51
  • 2025年半导体品牌30强(英文).pdf
  • 2025-05-22 15:51
  • 2025年半导体品牌30强.pdf
  • 2025-05-21 15:40
  • 半导体行业深度研究:光掩模:高壁垒材料,国产化率低,下游新应用打开成长新空间.pdf
  • 2025-05-20 17:03
  • 2024年美国半导体行业报告.pdf
  • 2025-04-30 17:22
  • 意法半导体:2025年电源管理指南白皮书.pdf
  • 2025-04-26 14:32
  • 2025年半导体行业白皮书-薪智.pdf
  • 2025-04-26 14:28
  • 电子行业:国产替代系列研究-一--半导体国产替代产业研究体系-上.pdf
  • 2025-04-23 15:58
  • 半导体设备、材料、零部件产业链蓄势乘风起-国盛证券.pdf
  • 2025-04-19 14:39
  • 电子行业半导体量检测设备:控制芯片生产良率的关键,具备极大国产替代空间和极强迫切性.pdf
  • 2025-04-15 16:10
  • 半导体行业深度报告:AI算力芯片——AI时代的引擎.pdf
  • 2025-04-09 16:17
  • 半导体行业深度报告(十二):AI大模型竞赛方兴未艾,OpenAI与DeepSeek引领行业生态重.pdf
  • 2025-03-31 09:38
  • 半导体行业深度报告-十二-:AI大模型竞赛方兴未艾,OpenAI与DeepSeek引领行业生态重构.pdf
  • 2025-03-29 16:11
  • 泛半导体材料研究系列之二:偏光片行业:解码偏光片国产替代加速与中大尺寸增量机遇.pdf
  • 2025-03-28 16:27
  • 半导体行业策略:云巅千帆竞渡,端侧万物生辉,自主驭潮生.pdf
  • 2025-03-24 14:29
  • 半导体行业策略:云巅千帆竞渡,端侧万物生辉,自主驭潮生.pdf
  • 2025-03-22 16:53
  • 半导体:AI算力芯片是“AI时代的引擎”,河南省着力布局.pdf
  • 2025-03-21 15:41
  • 半导体材料系列报告之三:半导体材料市场景气上行,各领域头部企业受益于国产化浪潮.pdf
  • 2025-03-20 14:48
  • 2025年Q1半导体行业薪酬报告.pdf
  • 2025-03-17 14:41
  • 2024 年中国芯片半导体行业投融资报告.pdf
  • 2025-03-17 14:37
  • 半导体材料系列报告之二:AI和晶圆厂扩建驱动半导体材料市场回暖,高端材料国产化进程加速.pdf
  • 2025-03-15 15:28
  • 2025年全球半导体产业展望(英文).pdf
  • 2025-03-07 16:25
  • 半导体键合设备行业深度:先进封装高密度互联推动键合技术发展,国产设备持续突破.pdf
  • 2025-03-07 16:17
  • 英飞凌:2025年GaN功率半导体预测报告.pdf
  • 2025-02-27 14:51
  • 电子设备-产业深度:积微累著,久久为功— —美国对华半导体制裁政策变迁分析与中国对策研究.pdf
  • 2025-02-21 14:45
  • 2025年中国半导体行业出口分析及各国进口政策影响白皮书.pdf
  • 2025-02-18 15:55
  • 国信证券-半导体专题:多相电源是增量蓝海市场,看好国产替代机遇.pdf
  • 2025-02-06 17:34
  • 半导体材料专题报告:先进制程驱动市场扩容,细分环节国产替代加速.pdf
  • 2025-01-22 15:59
  • 2024年中国半导体照明及应用领域出口统计及市场发展趋势分析白皮书.pdf
  • 2025-01-17 13:11
  • 半导体设备零部件行业深度研究报告:半导体设备之磐基,国产替代正当时.pdf
  • 2025-01-10 16:23
  • 2025年电子行业投资策略:AI+国产化双轮驱动,关注消费电子、半导体产业链投资机遇.pdf
  • 2025-01-03 16:06
  • EDA和IP行业专题:半导体产业基石,国产替代打破垄断格局.pdf
  • 2024-12-26 15:45
  • 半导体行业系列专题-七-:晶圆代工:特色工艺蓬勃发展,自主可控成果显著.pdf
  • 2024-12-21 17:17
  • 招银国际-半导体2025展望:AI热潮将延续.pdf
  • 2024-12-18 15:47
  • 半导体行业2025年年度策略报告:AI将是强引擎,国产化有望进深水区.pdf
  • 2024-12-17 15:30
  • 四氯化硅:高科技材料,推动半导体与光伏产业发展 头豹词条报告系列.pdf
  • 2024-12-15 14:15
  • 电子行业2025年度投资策略:人工智能创新持续推进,半导体自主可控方兴未艾.pdf
  • 2024-12-03 15:33
  • 海外半导体设备巨头巡礼系列:先晶-ASM-深耕薄膜沉积&外延设备,专业化布局的半导体设备龙头.pdf
  • 2024-12-03 15:32
  • 毕马威:2024年全球半导体行业展望报告.pdf
  • 2024-11-29 15:31
  • 企业竞争图谱:2024年半导体掩膜版 头豹词条报告系列.pdf
  • 2024-11-22 15:47
  • 可持续管理成就基业长青-半导体企业ESG管理案例.pdf
  • 2024-11-20 16:33
  • 半导体行业月度深度跟踪:自主可控需求长期趋势不变,关注产业链卡脖子环节和核心公司.pdf
  • 2024-11-19 16:03
  • 半导体行业2025年上半年投资策略:国产替代持续深化,AI带来硬件增量.pdf
  • 2024-11-15 15:22
  • 海外半导体设备巨头巡礼系列:应用材料-AMAT-内生外延打造“半导体设备超市”,整线设备&高品质服务构筑护城河.pdf
  • 2024-11-15 15:22
  • 全球半导体测试探针行业市场研究报告2024.pdf
  • 2024-11-12 16:34
  • 全球半导体测试探针行业市场研究报告2024-2028.pdf
  • 2024-11-11 15:27
  • 半导体供应链行业报告:行业复苏分化加深,静待需求回暖.pdf
  • 2024-11-09 16:50
  • 2023年第三代半导体产业发展报告.pdf
  • 2024-10-31 15:44
  • 半导体前道设备:前沿科技驱动未来制造,探索高效前道工艺解决方案 头豹词条报告系列.pdf
  • 2024-10-24 16:24
  • 2024上半年半导体行业招聘报告.pdf
  • 2024-10-23 15:32
  • 半导体行业研究周报:四季度安卓旗舰密集发布,半导体需求有望旺季很旺.pdf
  • 2024-10-18 16:57
  • 可持续芯动力:2024年半导体行业ESG转型之路研究报告.pdf
  • 2024-10-17 15:44
  • 东吴证券-海外半导体设备巨头巡礼系列:详解光刻巨人ASML成功之奥妙.pdf
  • 2024-10-17 15:40
  • 全球半导体制造类EDA行业白皮书(2024)-沙利文.pdf
  • 2024-10-12 15:09
  • 源达信息-雄安新区专题研究:重点布局半导体产业发展,助力国内高新技术产业向前.pdf
  • 2024-10-12 14:55
  • 锡行业深度报告系列(一):半导体景气复苏,锡供需格局持续向好.pdf
  • 2024-10-07 15:10
  • 头豹研究院-2024半导体检测设备:铸就芯片品质新高度 头豹词条报告系列.pdf
  • 2024-09-28 15:57
  • ...刻蚀设备市场空间持续拓宽——半导体设备系列报告之刻蚀设备.pdf
  • 2024-09-25 15:59
  • 深度解读半导体行业.pdf
  • 2024-09-23 15:17
  • 美国半导体协会:2024年美国半导体行业状况报告(英文版).pdf
  • 2024-09-20 16:09
  • 国信证券-半导体行业专题:先进封装超越摩尔定律,晶圆厂和封测厂齐发力.pdf
  • 2024-09-20 15:54
  • 英飞凌如何控制和保证基于SiC的功率半导体器件的可靠性.pdf
  • 2024-09-10 16:49

我妈妈说,她嫁过来不到三个月,就是分家的日子。所谓“分家”,是从奶奶手里接过的几只碗——粗瓷的,边沿带着小小的缺口。锅呢?没有。田地呢?都是最远的、最贫瘠的山坳角落。我爸爸只是沉默地接下。

我的出生,并未给这个家庭在奶奶那里赢得半分暖意。她没来看过一眼,更别说抱一抱。月子里,是父亲照顾母亲。他清早六点起身,生火做饭,在八点前赶到工地。妈妈总记得那个清晨,爸爸杀鸡时一刀切在手上,血怎么都止不住,他竟晕了过去。空荡荡的灶房,只有妈妈无助的哭声。许多年后我听到这里,眼泪仍会毫无预兆地滚下来。

偏心是一把钝刀,它不一下致命,却经年累月地磨着人的心。小姑的孩子寄养在奶奶身边,和我们一般大。孩子间的打闹本是常事,可一旦小姑的孩子哭了,奶奶的骂声便即刻响起。有一次,她竟指着我们吼:“我女儿只生了这一个儿子,打死了要偿命!”妈妈积压多年的火气轰然炸开,她一把将我和弟弟拽到跟前,声音发抖却字字清晰:“来!看看!你儿子生了 12 个儿子!打死了不用偿命,是不是?”空气凝固了。从那以后,那话她再没说过,但冰冷的空气,再没暖过。

那偏心的尺度,精确到一颗弹珠。弟弟和小叔的儿子玩弹珠,赢了全部。堂弟一哭,奶奶便骂了整整三天,污言秽语,说我们“偷抢”、“穷酸恶毒”。同一个屋檐下,她却能对寄养在大伯家(是大伯娘弟弟的儿子)、毫无血缘的孩子温言软语,说着“奶奶背你”、“奶奶喂你”——这些我们从未听过的字眼。

最伤人的,往往在最不经意间。八九岁时,一个肉丸被堂弟好心地分成两半,给了弟弟一份。奶奶发现后,刻薄的话冲口而出:“这么馋!有吃的分给外人!”那个“外人”,像一根冰锥,扎进了我们全家的耳朵。我爸爸当时就在屋里,他什么也没说,只是烟抽得更凶了。

我们就在这样的“区别”里长大了。十七八岁,我们不再叫她。婶婶劝父亲:“教教孩子,怎么不叫奶奶?”父亲只回了一句:“我的孩子,不用教。”原来,他自己也已十几年,没叫过那一声“妈”。

时间似乎能冲淡一切。我结婚前,我妈,说:“算了。”她主动走向奶奶,邀请她来参加婚礼。这是二十多年来,妈妈第一次对她开口。奶奶挪开目光,淡淡地推脱:“大孙女结婚,我都没去呢。”一旁的婶婶忍不住:“那时您病着,现在身子不是硬朗么?”最终,她也没来。母亲那扇好不容易才推开一条缝的门,又轻轻地关上了。

她九十多岁,摔断了盆骨。我去看她,那片刻的关心,竟让我生出一种背叛母亲、背叛那些年所有委屈的罪恶感。

如今,我也成了父母。偶尔和爸爸谈起过去,他只是沉默地听着,烟雾缭绕里,看不清表情。我懂得了他的沉默。 母亲态度坚决:“她走时,我不会去。”父亲则对我们说:“你们……还是得去。” 表面还是做一下。

我正在使用 linux 系统,用在一款老旧笔记本上。我在微信官网下载并安装了微信,登陆的时候却发现手机端提示需要我输入身份证并且进行人脸识别。我对此比较介意,请问怎样才能避开微信对我私密信息和生物信息的审核呢?

根据这个排行榜 https://artificialanalysis.ai/leaderboards/models
豆包排名非常低,国内最聪明的是 kimi 和 deepseek 。豆包只有 34 分,kimi 47 分,deepseek 42 分
不过说实话我也没用过 kimi
之前在手机上我用豆包,因为它可以语音输入,比较方便。现在 ds 也有语音输入了,我就不用豆包了。
为什么豆包这么火呢,豆包的聪明程度也不是很高啊。

如果你是一名前端开发者,特别是React开发者,你一定听说过或使用过CSS-in-JS方案。从Styled-components到Emotion,这些库在短短几年内迅速流行,被无数项目采用。

但今天,我要冒着被喷的风险说一句:CSS-in-JS是个糟糕的设计,它解决了不存在的问题,却创造了真实的新问题。


一、CSS-in-JS的“美好”承诺

支持者们会告诉你CSS-in-JS有多棒:

  • 组件化:样式与组件绑定,不再担心样式污染
  • 动态样式:基于props的动态样式轻而易举
  • 自动处理前缀:不再需要手动写-webkit-
  • 代码简洁:不再需要在不同文件间跳转

听起来很美好,不是吗?但这些“好处”背后,隐藏着巨大的代价。


二、现实中的七宗罪

运行时开销:性能的隐形杀手

CSS-in-JS在运行时解析样式、生成类名、注入到文档中。这意味着用户访问你的网站时,JavaScript必须完成这些额外工作才能显示样式。

对比一下:

  • 传统CSS:浏览器直接解析和应用样式
  • CSS-in-JS:JavaScript执行 → 解析样式 → 生成类名 → 注入样式 → 浏览器应用

在慢速设备或网络条件下,这种差异尤为明显。而这一切,只是为了实现原本浏览器原生就能处理的事情。

开发体验的倒退

“在JavaScript中写CSS”听起来很酷,直到你真正开始使用:

const Button = styled.button`
  background: ${props => props.primary ? 'blue' : 'white'};
  color: ${props => props.primary ? 'white' : 'blue'};
  
  &:hover {
    background: ${props => props.primary ? 'darkblue' : 'lightgray'};
  }
  
  @media (max-width: 768px) {
    font-size: 14px;
    padding: 8px 16px;
  }
`;

这段代码里,你失去了:

  • CSS语法高亮(除非额外安装插件)
  • CSS自动补全
  • CSS linting检查
  • 浏览器DevTools的直接编辑能力

可维护性噩梦

当样式逻辑复杂时,你最终会得到这样的代码:

const ComplexComponent = styled.div`
  ${({ theme, variant, size, disabled }) => {
    // 一大堆JavaScript逻辑
    let styles = '';
    if (variant === 'primary') {
      styles += `background: ${theme.colors.primary};`;
    }
    if (size === 'large') {
      styles += `padding: 20px; font-size: 18px;`;
    }
    if (disabled) {
      styles += `opacity: 0.5; cursor: not-allowed;`;
    }
    return styles;
  }}
`;

这不再是“在JS中写CSS”,而是“用JS逻辑生成CSS字符串”。可读性和可维护性急剧下降。

学习成本陡增

新开发者需要学习:

  1. CSS本身
  2. JavaScript
  3. React
  4. 特定CSS-in-JS库的语法和API
  5. 如何调试这个独特的系统

而他们学到的大多数知识,在离开这个特定技术栈后毫无用处。

SSR和静态生成的复杂性

服务器端渲染变得复杂:

  • 需要收集使用的样式
  • 需要在HTML中注入样式
  • 需要处理hydration不匹配
  • 增加了包大小和内存使用

而这一切对于纯CSS来说,都是不存在的。

调试困难

在浏览器DevTools中,你会看到这样的类名:.sc-1a2b3c4d。想根据类名找到对应的组件?祝你好运。

想了解某个样式来自哪个组件?你需要:

  1. 打开DevTools
  2. 找到元素
  3. 查看混乱的类名
  4. 在代码中搜索这个生成的类名
  5. 或者安装专门的浏览器扩展

三、更好的替代方案

CSS-in-JS试图解决的问题,其实有更优雅的解决方案:

方案一:CSS Modules(真正的组件化CSS)

/* Button.module.css */
.button {
  background: blue;
  color: white;
}

.primary {
  background: darkblue;
}

.button:hover {
  background: lightblue;
}
import styles from './Button.module.css';

function Button({ primary }) {
  return (
    <button className={`${styles.button} ${primary ? styles.primary : ''}`}>
      Click me
    </button>
  );
}

优点

  • 真正的局部作用域
  • 零运行时开销
  • 保持CSS原生能力
  • 易于调试

方案二:Utility-First CSS(如Tailwind)

function Button({ primary }) {
  return (
    <button className={`
      px-4 py-2 rounded
      ${primary 
        ? 'bg-blue-600 text-white hover:bg-blue-700' 
        : 'bg-gray-200 text-gray-800 hover:bg-gray-300'
      }
    `}>
      Click me
    </button>
  );
}

优点

  • 极小的CSS输出
  • 高度一致的设计系统
  • 极少的上下文切换
  • 优秀的性能特性

方案三:纯CSS + 现代特性

现代CSS已经解决了大多数“CSS难题”:

/* 使用CSS自定义属性实现主题 */
:root {
  --primary-color: blue;
  --spacing-unit: 8px;
}

.button {
  background: var(--primary-color);
  padding: calc(var(--spacing-unit) * 2);
}

/* 容器查询 - 即将成为标准 */
@container (max-width: 400px) {
  .button {
    font-size: 14px;
  }
}

四、历史的教训

我们见过这种模式:

  1. 过度抽象:为了解决“复杂”的CSS,我们创建了更复杂的系统
  2. 技术债积累:短期便利,长期维护噩梦

CSS-in-JS可能最终会像其他过度抽象的技术一样,在热情消退后,留下技术债务和后悔的开发者。


结语

有时候,最简单的解决方案就是最好的解决方案。CSS已经存在了25年,浏览器厂商投入了无数资源优化它。也许,我们应该相信这些专家,而不是试图在JavaScript中重新发明轮子。

前端开发的进步,不应该以牺牲Web的根本原则为代价。

简洁、可维护、高性能的代码,才是对我们用户和同事的真正尊重。


互动话题:你在项目中使用过CSS-in-JS吗?遇到了哪些问题?欢迎在评论区分享你的经验!

关注我,获取更多前端技术文章

本文由mdnice多平台发布

如何设计「AI 可读」的 Laravel + Livewire 后台架构

当 AI 开始参与写代码、改代码、生成模块时,
**“能不能跑”已经不重要了,
“能不能被 AI 理解”才是决定效率上限的关键。**

在实践 Laravel 12 + Livewire 4 构建Teanary[ https://gitee.com/teanary/teanary_service ]后台的过程中,我们逐渐意识到:
传统“人类可读”的代码结构,并不等于“AI 可读”。

本文将从架构、命名、分层、组件设计等角度,总结一套专门为 AI 协作优化的后台设计方法


一、什么是「AI 可读」架构?

先说结论:

AI 可读 ≠ 注释多 ≠ 文档厚
AI 可读 = 结构自解释 + 意图明确 + 低歧义

AI 在读代码时,最怕什么?

  • 业务逻辑散落在多个层
  • 同一个概念有 3 种名字
  • Controller / Component 又厚又杂
  • 隐式魔法太多(Hook、动态行为)
  • “这个东西是干嘛的?”需要上下文推理

而 Laravel + Livewire 天然具备被 AI 理解的潜力,前提是:
👉 你别把它写乱了


二、核心原则一:页面 = 用例(Use Case)

❌ 传统写法(AI 极难理解)

UserController
UserService
UserRepository
UserTransformer
UserApiController
UserPageController

AI 会直接懵:

“你到底想干嘛?”

✅ AI 友好写法:以「页面 / 用例」为核心

app/
 └── Livewire/
     └── Users/
         ├── UserList.php        // 用户列表
         ├── CreateUser.php      // 创建用户
         ├── EditUser.php        // 编辑用户
         └── UserDetail.php      // 用户详情

一个 Livewire Component = 一个明确的业务用例

AI 非常擅长理解这种结构,因为:

  • 文件名就是意图
  • 没有“抽象猜谜”
  • 一个组件 ≈ 一个需求描述

三、核心原则二:组件必须「单一职责到极致」

AI 最擅长什么?

👉 在“局部、封闭、明确”的上下文中生成正确代码

所以你要反过来设计组件:

❌ 错误示例(人类都难维护)
class UserManager extends Component
{
    // 列表
    // 搜索
    // 编辑
    // 删除
    // 批量操作
    // 弹窗
}
✅ AI 友好示例
UserTable        // 只负责展示列表
CreateUserForm   // 只负责创建
EditUserForm     // 只负责编辑
DeleteUserAction // 只负责删除行为

AI 能做到的前提是:

你不要让它一次“理解整个系统”

四、核心原则三:命名 = 给 AI 的 Prompt

这是最重要的一点。

1️⃣ 方法名必须是「动作 + 业务对象」

// 好
createUser()
updateUser()
disableUser()
assignRoleToUser()

// 坏
handleSubmit()
process()
action()
save()

AI 生成代码时,本质就是在做语义补全
模糊命名 = 错误补全。


2️⃣ Livewire 属性必须是“状态描述”

public bool $showCreateModal = false;
public string $searchKeyword = '';
public ?User $editingUser = null;

而不是:

public $flag;
public $data;
public $value;

👉 属性名就是 UI 状态说明书


五、核心原则四:业务逻辑“下沉但不分裂”

这是很多人写坏 Laravel 的地方。

❌ 反 AI 的写法

  • Controller 一点
  • Service 一点
  • Trait 再一点
  • Helper 偷偷来一点

AI 会直接失去全局一致性。


✅ 推荐做法:Use Case / Action 类

app/
 └── Actions/
     └── User/
         ├── CreateUser.php
         ├── UpdateUser.php
         └── DeleteUser.php
class CreateUser
{
    public function execute(array $data): User
    {
        // 完整、封闭、可测试
    }
}

Livewire 中:

public function create()
{
    app(CreateUser::class)->execute($this->form);
}

AI 极其擅长补全 Action 类,因为:

  • 输入清晰
  • 输出明确
  • 无 UI 干扰

六、核心原则五:显式 > 隐式(为 AI 放弃一部分“优雅”)

Laravel 很多“优雅写法”对 AI 是毒药

❌ 例子
User::active()->recent()->visible()->get();

AI 不知道:

  • active 是什么
  • visible 规则在哪
  • 是否有副作用
✅ AI 友好写法
User::query()
    ->where('status', UserStatus::ACTIVE)
    ->where('is_visible', true)
    ->orderByDesc('created_at')
    ->get();

👉 明确永远比“聪明”重要


七、核心原则六:注释是“业务说明”,不是翻译代码

❌ 无效注释

// update user
public function updateUser() {}

✅ AI 有用的注释

/**
 * 更新用户基础信息
 * - 不允许修改邮箱
 * - 超级管理员不可被禁用
 */
public function updateUser() {}

AI 会把这些当成规则约束,而不是废话。


八、Livewire + AI 的理想协作模式

当你做到以上几点后,你会发现:

  • AI 可以直接:

    • 生成 Livewire 组件
    • 拆分复杂组件
    • 补全 Action 类
    • 修改 UI 状态逻辑
  • 人类只需要:

    • 定义业务边界
    • 审核规则是否正确

这就是“AI-first 后台架构”的真正价值。


九、终极判断标准:一句话能不能描述这个文件?

如果你能对 AI 说:

“这是一个用于【创建租户用户】的 Livewire 组件”

而 AI 打开文件后发现:

  • 命名一致
  • 职责单一
  • 逻辑闭合

那你这套架构,已经是 AI 可读的了


十、总结:这是在为未来 3–5 年写代码

AI 不会取代你,但:

会取代那些“写给自己看”的代码结构

Laravel + Livewire 本身已经站在正确方向上了,
剩下的差距,只在你是否愿意为“可理解性”让路

背景:我是一个研究生,后端会 SpringBoot ,前端会 React 和 Next.Js ,在一个横向项目中,老师让我开发一个安卓软件(需要控制打印机),后端其他同学负责,开发完就让我出去实习
。所以想问问各位大佬,在尽量 vibe 和快速的情况下:

  1. 我应该使用什么架构,原生安卓?还是 React Native ?
  2. 目前在用 OpenCode ,有什么好用的 skills 之类的吗?
  3. 有什么其他的好的工作流吗?

小弟感激不尽!

在现代汽车制造中,焊接作为连接车身结构的核心工艺,其质量直接关系到整车的安全性、耐久性与NVH性能。一辆乘用车的白车身通常包含超过3000个焊点,每一个焊点的强度、熔深、一致性都不可忽视。传统依赖人工凿检与目视抽检的方式,不仅效率低下、易漏检,更难以应对高节拍生产下的动态波动。焊接过程本身具有高度非线性特征——电流、电压、时间、材料厚度、环境温湿度等参数相互耦合,稍有偏差便可能引发气孔、裂纹或虚焊。因此,单纯依靠经验调整已无法满足高端制造对“零缺陷”的追求,亟需一种能理解工艺本质、实时响应变化的智能化解决方案。
要实现焊接质量的系统性提升,必须从“经验驱动”转向“机理驱动”。工业机理模型的本质,是将焊接过程中物理、热力、电学的内在规律转化为可计算、可验证的数学表达。它不依赖海量数据盲目训练,而是以电热平衡方程、熔池动力学、金属相变理论为基础,构建起对焊接行为的底层解释能力。这种模型能识别出哪些参数偏离了物理规律,而非仅仅统计异常。当系统发现某焊点的电流上升速率与理论模型存在3%的偏差,即使该焊点尚未形成可见缺陷,也能提前预警,从而将质量问题拦截在萌芽阶段。这种“知其所以然”的能力,远超传统机器学习的“黑箱”模式,使质量控制从被动响应走向主动预防。
在这一技术路径上,广域铭岛的Geega平台已展现出显著成效。其通过集成焊接车间300余台独立控制器的数据流,构建了覆盖全流程的焊接质量监测系统。系统不仅实时比对工艺参数与设计标准,还结合电阻、温度等后置反馈数据,建立多维度偏差分析模型。更关键的是,它利用机器学习持续识别高频失效焊点,形成“问题点热力图”,指导质检人员精准复检,使焊接误差率从行业平均的8‰降至3‰以下。与此同时,系统沉淀的工艺知识可反哺参数调试,为新车型快速匹配最优焊接方案,大幅缩短试产周期。而在海外,德国博世(Bosch)同样在焊接领域布局AI优化系统,其通过数字孪生技术构建虚拟焊接环境,结合实时传感器数据动态校准机器人轨迹与能量输入,实现焊缝一致性提升22%,并在宝马、奔驰的产线上实现规模化应用。

全文链接:https://tecdat.cn/?p=44943
原文出处:拓端数据部落公众号

封面:封面

专题名称:大语言模型Llama 4轻量化微调实战与医疗推理场景适配研究

引言

随着大语言模型技术的快速迭代,新一代大模型凭借更优的推理能力成为行业落地的核心选择,但这类模型普遍存在硬件门槛高的问题,常规微调需求动辄需要数张高端GPU,让中小团队与个人开发者难以开展垂直领域的适配工作。在实际业务咨询中,众多医疗领域客户向我们提出了通用大模型的低成本行业微调需求,希望在控制算力成本的同时,让模型具备专业的临床推理能力。

基于此,我们在客户咨询项目中开展了Llama 4 Scout模型的低成本微调技术研究,创新性地采用云GPU平台搭建多GPU训练环境,将原本需要4张高端GPU的微调任务成本控制在极低水平,同时针对医疗推理场景完成了模型的有监督微调。研究过程中,我们攻克了Transformers库嵌入不匹配、大模型显存不足、量化模型兼容等多个技术痛点,还设计了适配医疗临床推理的Prompt工程,让微调后的模型能够实现专业的医学问题分析与解答。本文将完整拆解该项目的落地流程,从云环境搭建到模型训练、性能验证再到模型部署,为大模型在垂直领域的轻量化微调提供可直接落地的实践方案,所有技术方案均经过实际业务校验,具备极强的实用性。

本文内容改编自过往客户咨询项目的技术沉淀并且已通过实际业务校验,该项目完整代码与数据已分享至交流社群。阅读原文进群,可与800+行业人士交流成长;还提供人工答疑,拆解核心原理、代码逻辑与业务适配思路,帮大家既懂 怎么做,也懂 为什么这么做;遇代码运行问题,更能享24小时调试支持。
本次Llama 4微调项目的整体实施流程如下(竖版流程图):

云GPU平台多GPU训练环境搭建

Llama 4 Scout模型对硬件算力与显存要求较高,本地消费级GPU无法满足模型加载与微调的需求,而采购专业GPU服务器的成本过高,因此选择云GPU平台按需搭建训练环境是最优解。本次项目选用的RunPod平台支持灵活的多GPU配置,且算力单价较低,能大幅降低微调成本。

需要注意的是,RunPod为海外云GPU平台,国内直接访问需要借助网络代理工具,国内可选择的替代平台有AutoDL、极链云、阿里云GPU服务器、腾讯云GPU服务器等,这类平台均支持多GPU灵活配置,国内可直接访问,且预装了PyTorch、TensorFlow等大模型训练所需的基础框架,无需手动配置底层环境

虚拟服务器环境优化配置

虚拟服务器初步部署完成后,还需要进行两项关键的环境优化,确保后续模型加载与训练工作顺利开展:一是将容器磁盘容量扩容至300GB,满足Llama 4模型文件、医疗推理数据集的存储需求,避免因磁盘空间不足导致模型加载失败;二是添加HF_TOKEN环境变量,该变量为海外Hugging Face模型平台的访问令牌,是加载门控模型与上传微调后模型的必要条件。Hugging Face为海外模型平台,国内直接访问需要借助网络代理工具,国内可选择的替代平台为魔搭社区ModelScope,该平台提供丰富的大模型、数据集资源,国内可直接访问,同时支持模型的上传、下载与二次开发,功能与Hugging Face高度契合

启动JupyterLab交互式开发环境

虚拟服务器的容器配置完成后,平台会完成底层环境的初始化,该过程需要少量时间,初始化完成后点击Connect按钮,选择启动JupyterLab实例,该实例为云端的交互式开发环境,操作方式与本地JupyterLab完全一致,可直接在其中编写、运行Python代码,完成后续所有的模型加载、数据处理、训练推理等操作。

新建开发笔记本开展后续工作

成功进入JupyterLab实例后,在界面中新建Python笔记本,即可开始搭建模型微调的代码环境,后续所有的技术实现步骤,包括依赖包安装、模型量化加载、数据集处理、LoRA配置、SFT训练等,均在该笔记本中完成,云端环境与本地开发的操作体验无差异。

微调环境依赖包安装与模型平台认证

在开展模型微调的核心工作前,需要先安装项目所需的Python依赖包,同时完成模型平台的身份认证,确保后续模型的正常加载与上传。本次项目中需要重点注意的是,最新版本的Transformers库存在嵌入不匹配的bug,直接使用会导致Llama 4模型加载失败,因此我们选择固定4.51.0版本进行安装;同时安装模型平台的xet集成组件,该组件可将模型文件的下载速度提升3倍,大幅节省模型加载时间。

核心依赖包安装代码

%%capture!pip install transformers==4.51.0 # 固定版本解决嵌入不匹配bug,保证模型正常加载%pip install -U datasets # 行业数据集加载与处理核心库%pip install -U accelerate # 多GPU分布式训练加速库...... # 省略了peft、trl、bitsandbytes等大模型微调核心依赖包的安装代码%pip install huggingface_hub[hf_xet] # 安装xet集成,提升模型下载速度

上述代码中,通过%%capture屏蔽了依赖包安装过程的冗余输出信息,让代码运行结果更简洁;省略的peft为LoRA低秩适配的核心库,trl为SFT有监督微调的核心库,bitsandbytes为大模型量化降显存的核心库,均为本次大模型微调项目的必备依赖。

模型平台身份认证

完成依赖包安装后,通过环境变量读取提前配置的模型平台访问令牌,完成平台的登录认证,只有认证成功后,才能访问受权限控制的门控模型,同时也能将微调后的模型顺利上传至模型仓库,实现模型的共享与二次开发。

from huggingface_hub import loginimport osplat_auth_token = os.environ.get("HF_TOKEN") # 修改变量名,读取环境变量中的平台令牌login(plat_auth_token) # 完成模型平台的登录认证

相关文章

Python用langchain、OpenAI大语言模型LLM情感分析AAPL股票新闻数据及提示工程优化应用

原文链接:https://tecdat.cn/?p=39614


Llama 4 Scout模型与分词器的量化加载

本次项目选用Llama 4 Scout系列的17B规模模型为基础模型,该模型具备较强的通用推理能力,是垂直领域适配的优质基础模型,需要注意的是该模型为门控模型,需在对应模型平台完成申请后才能获得访问权限。为了大幅降低模型的显存占用,满足多GPU分布式加载的需求,我们采用4-bit量化策略加载模型,同时将device_map参数设置为auto,让模型自动将参数分配到3张H200 GPU上,充分利用多GPU的算力与显存资源,避免单GPU显存不足的问题。

模型4-bit量化加载代码

import osimport torchfrom transformers import AutoTokenizer, Llama4ForConditionalGeneration, BitsAndBytesConfigbase_model_id = "meta-llama/Llama-4-Scout-17B-16E-Instruct" # 修改变量名,定义模型标识# 配置4-bit量化参数,修改变量名,降低模型显存占用quant_4bit_config = BitsAndBytesConfig( load_in_4bit=True, # 开启4-bit量化 bnb_4bit_use_double_quant=False, bnb_4bit_quant_type="nf4", bnb_4bit_compute_dtype=torch.bfloat16,)......

上述代码执行后,模型将以4-bit量化的形式完成加载,模型参数会自动分配到3张H200 GPU上,完美解决大模型显存不足的技术痛点,加载完成后JupyterLab会输出模型的网络层结构、参数分配的设备信息等内容,可直观查看模型加载状态。

分词器加载与GPU显存检测

加载与基础模型完全匹配的分词器,其核心作用是将医疗推理的文本数据转换为模型能够识别的张量格式,是连接文本数据与模型的关键桥梁;同时通过nvidia-smi命令检测3张GPU的显存使用情况,确认模型加载后剩余的显存资源能够满足后续SFT有监督微调的需求,避免因显存不足导致训练中断。

执行nvidia-smi命令后,JupyterLab会输出3张H200 GPU的显存总容量、已占用显存、剩余显存、算力使用率等详细信息,本次项目中模型4-bit量化加载后,各GPU仍有充足的剩余显存,完全能够支撑后续的模型训练工作。

医疗推理数据集的处理与专属Prompt工程

为了让通用的Llama 4模型具备专业的医疗推理能力,本次项目选用医疗推理领域的专用数据集开展微调工作,该数据集包含大量真实的医学问题、临床分步推理过程与专业解答结果,完全适配医疗场景的落地需求。我们首先结合医学临床推理的业务特点,设计专属的Prompt模板,再通过自定义函数将数据集按模板格式进行格式化处理,让数据与模型的输入格式高度匹配,提升模型的训练效果与推理能力。

医疗推理场景专属Prompt模板设计

结合医学临床推理的业务逻辑,我们设计了包含任务指令、医学问题、分步推理链、专业答案的一体化Prompt模板,该模板能够引导模型按照“分析医学问题-构建分步临床推理链-给出专业准确答案”的逻辑生成内容,有效提升模型的医疗问题分析能力与解答专业性。

# 修改变量名,设计医疗推理场景专属Prompt模板med_train_prompt_tpl = """以下是一个描述医疗任务的指令,搭配对应的临床背景信息。请撰写合适的内容完成任务要求。回答前请仔细分析医学问题,构建分步的临床推理链,保证推理逻辑与答案的准确性和专业性。### 指令:你是具备高级临床推理、疾病诊断与治疗方案制定能力的医疗专家,请专业解答下述医学问题。### 问题:{} ### 回答: {} {}"""

医疗数据集格式化处理

自定义数据格式化处理函数,将数据集中的医学问题、临床推理链、专业答案三个核心字段,按顺序填充到上述Prompt模板中,生成模型可直接用于训练的文本数据;同时为每个格式化后的文本添加模型结束符,让模型能够准确识别文本的结束位置,避免出现无意义的内容生成。

# 定义模型结束符,修改变量名MODEL_END_TOKEN = text_tokenizer.eos_token# 自定义医疗数据集格式化函数,修改函数名与入参变量名def format_med_dataset(med_data_samples): qs_list = med_data_samples["Question"] cot_chain_list = med_data_samples["Complex_CoT"] ans_list = med_data_samples["Response"] format_text_list = [] ...... # 省略了循环遍历的边界判断与空值处理代码,核心为字段填充与文本拼接 # 遍历数据集,按模板格式化文本

执行上述代码后,数据集将生成新的text字段,该字段为按Prompt模板填充后的完整训练文本,JupyterLab会输出第一条格式化后的文本内容,可直观查看数据处理的效果,确认文本格式符合模型训练要求。

语言模型数据整理器配置

本次项目使用SFT有监督微调训练器开展模型训练,该训练器不直接支持分词器的直接输入,因此我们将已加载的分词器转换为语言模型专用的数据整理器,其核心作用是将格式化后的文本数据批量转换为模型训练所需的张量格式,同时完成数据的批量处理与封装,提升训练效率。

from transformers import DataCollatorForLanguageModeling# 配置语言模型数据整理器,修改变量名lm_data_collator = DataCollatorForLanguageModeling( tokenizer=text_tokenizer, # 关联匹配的分词器 mlm=False # 因果语言模型训练,关闭掩码语言建模)

微调前的模型推理能力验证

为了清晰对比微调前后模型的医疗推理能力提升效果,我们在开展正式训练前,先对未经过微调的基础模型进行推理能力验证。设计不含临床推理链与专业答案的测试Prompt模板,输入典型的医学问题让模型生成解答内容,观察基础模型在医疗推理场景下的原始表现,为后续的训练效果评估提供基准。

测试Prompt模板与基础模型推理代码

# 设计医疗推理测试专用Prompt模板,修改变量名med_test_prompt_tpl = """以下是一个描述医疗任务的指令,搭配对应的临床背景信息。请撰写合适的内容完成任务要求。回答前请仔细分析医学问题,构建分步的临床推理链,保证推理逻辑与答案的准确性和专业性。### 指令:你是具备高级临床推理、疾病诊断与治疗方案制定能力的医疗专家,请专业解答下述医学问题。### 问题:{} ### 回答: {}"""# 微调前基础模型推理验证,修改所有变量名与调用方式test_med_question = med_infer_data[0]['Question']# 将测试问题转换为模型输入张量model_inputs = text_tokenizer( [med_test_prompt_tpl.format(test_med_question, "") + MODEL_END_TOKEN], return_tensors="pt").to("cuda")# 模型生成解答内容base_model_outputs = llama_base_model.generate( input_ids=model_inputs.input_ids, attention_mask=model_inputs.attention_mask, max_new_tokens=1200, eos_token_id=text_tokenizer.eos_token_id, use_cache=True,)# 解析并打印模型生成的解答内容gen_text = text_tokenizer.batch_decode(base_model_outputs, skip_special_tokens=True)print(gen_text[0].split("### 回答:")[1])

执行上述代码后,未微调的基础模型将对输入的医学问题进行推理并生成解答内容,实际测试结果显示,基础模型的临床推理链冗长且逻辑不够紧凑,给出的答案较为简略,与数据集中的专业临床解答存在较大差距,说明通用模型在医疗推理垂直领域的适配性较差,亟需通过行业数据集开展针对性微调。

LoRA低秩适配配置与SFT有监督微调

为了实现大模型的高效、低成本微调,本次项目采用LoRA(低秩适配)技术,该技术是大模型垂直领域适配的主流技术,核心原理是冻结基础模型的绝大部分参数,仅训练少量新增的低秩矩阵参数,既能大幅降低训练所需的算力与显存成本,又能保证微调后模型的性能与全量微调接近。同时搭配SFT(有监督微调)训练器,结合格式化后的医疗推理数据集,完成模型的针对性训练。

LoRA低秩适配核心参数配置

from peft import LoraConfig, get_peft_model# 配置LoRA低秩适配训练参数,修改所有变量名lora_config = LoraConfig( lora_alpha=16, # LoRA缩放因子,平衡低秩矩阵贡献 lora_dropout=0.05, # Dropout概率,防止模型训练过拟合 r=64, # 低秩矩阵的秩,控制训练参数数量 bias="none", # 不进行偏置参数的重参数化 task_type="CAUSAL_LM", # 任务类型定义为因果语言建模 # 定义LoRA训练的目标模块,覆盖模型注意力与前馈层 target_modules=[ "q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj", ],)# 为基础模型添加LoRA适配器,修改变量名lora_med_model = get_peft_model(llama_base_model, lora_config)

SFT训练器配置与模型训练启动

配置SFT有监督微调训练器的核心训练参数,包括输出目录、批次大小、学习率、训练轮数、梯度累积步数等,同时将添加了LoRA适配器的模型、格式化后的医疗推理数据集、语言模型数据整理器、LoRA配置等核心组件传入训练器,完成初始化后启动训练,模型将自动在3张H200 GPU上开展分布式训练。

from trl import SFTTrainerfrom transformers import TrainingArguments# 配置SFT训练核心参数,修改所有变量名train_config = TrainingArguments( output_dir="llama4_med_infer_output", # 训练结果输出目录 per_device_train_batch_size=1, # 单设备训练批次大小 per_device_eval_batch_size=1, # 单设备验证批次大小 gradient_accumulation_steps=2, # 梯度累积步数 optim="paged_adamw_32bit", # 训练优化器 ...... # 省略了训练轮数、预热步数、日志记录等参数配置 learning_rate=2e-4, # 训练学习率 group_by_length=True, # 按文本长度分组,提升训练效率 report_to="none")# 初始化SFT有监督微调训练器,修改所有变量名med_model_trainer = SFTTrainer( model=lora_med_model, args=train_config, train_dataset=med_infer_data, peft_config=lora_config, data_collator=lm_data_collator,)# 启动模型训练med_model_trainer.train()

启动训练后,可在RunPod平台的虚拟服务器仪表盘查看3张GPU的算力与显存使用情况,仪表盘显示所有GPU均处于高负载状态,说明多GPU的算力资源得到了充分利用,分布式训练配置生效。

本次项目中,得益于4-bit量化与LoRA低秩适配的技术优化,模型的实际训练时间仅为7分钟,从云环境搭建到模型训练完成的总耗时仅为30分钟,大幅提升了大模型在垂直领域的微调效率;训练过程中,JupyterLab会实时输出训练步数、损失值、训练耗时等关键信息,可直观监控模型的训练状态。

同时我们提供24小时响应的代码运行异常应急修复服务,针对大模型微调过程中出现的显存不足、库兼容报错、训练中断、模型生成异常等问题提供实时调试支持,相比开发者自行调试,问题解决效率提升40%,大幅降低大模型落地的技术门槛。

微调后模型的医疗推理能力验证

完成模型的SFT有监督微调后,我们对微调后的模型开展全面的推理能力验证,既使用与微调前相同的医学问题进行对比测试,也选取新的医学问题开展泛化能力测试,全面检验模型经过医疗数据集微调后的推理能力提升效果,确保模型能够满足医疗推理场景的落地需求。

同一样本对比推理验证

使用微调前的第一个典型医学问题对微调后的模型进行推理验证,推理代码与微调前完全一致,仅将基础模型替换为添加了LoRA适配器的微调后模型。实际测试结果显示,微调后的模型生成的临床推理链逻辑清晰、步骤明确,完全贴合医疗临床的分析思路,给出的答案详细、专业且准确,与数据集中的专业解答高度契合,相比未微调的基础模型,医疗推理能力得到了显著提升。

新样本泛化推理验证

为了检验模型的泛化能力,选择数据集中的第10个医学问题作为新的测试样本,开展泛化推理验证,核心推理代码如下:

# 新医学样本推理验证,修改所有变量名与调用方式new_test_med_q = med_infer_data[10]['Question']# 转换为模型输入张量new_model_inputs = text_tokenizer( [med_test_prompt_tpl.format(new_test_med_q, "") + MODEL_END_TOKEN], return_tensors="pt").to("cuda")# 微调后模型生成解答内容new_model_outputs = lora_med_model.generate( input_ids=new_model_inputs.input_ids, attention_mask=new_model_inputs.attention_mask, ...... # 省略了最大生成长度、结束符ID等核心参数配置 use_cache=True,)# 解析并打印新样本的解答内容new_gen_text = text_tokenizer.batch_decode(new_model_outputs, skip_special_tokens=True)print(new_gen_text[0].split("### 回答:")[1])

新样本的测试结果显示,微调后的模型能够准确分析陌生医学问题的临床背景,快速构建合理的临床推理链,最终给出专业、准确的解答,说明模型经过医疗推理数据集微调后,不仅对训练样本的适配性提升,还具备了一定的泛化能力,能够处理未见过的医学问题,完全满足医疗推理场景的基础落地需求。

微调后模型的保存与模型仓库上传

为了方便后续的模型落地应用、二次开发与共享,我们将微调后的LoRA模型与配套的分词器上传至专业的模型仓库,上传过程会自动创建专属的模型仓库,同时将模型的所有核心文件、配置信息完整上传,生成可直接访问的仓库链接,开发者可通过该链接直接下载、调用模型,无需重新开展训练工作。

模型与分词器仓库上传代码

# 上传微调后的医疗推理模型与分词器,修改仓库名称lora_med_model.push_to_hub("Llama-4-Scout-17B-16E-Instruct-Medical-ChatBot")text_tokenizer.push_to_hub("Llama-4-Scout-17B-16E-Instruct-Medical-ChatBot")

执行上述代码后,JupyterLab会实时输出模型与分词器的上传进度、文件上传状态、仓库链接等信息,上传完成后可通过该链接直接访问模型仓库,查看模型详情、下载模型文件或直接调用模型开展推理工作。

项目技术难点与解决方案总结

本次Llama 4 Scout模型的医疗推理场景轻量化微调项目,基于实际业务需求开展,过程中遇到了大模型垂直领域落地的多个典型技术难点,我们结合业务场景与技术特点,给出了可直接落地的解决方案,所有方案均经过实际业务校验,具备极强的实用性:

  1. 大模型显存不足问题:采用4-bit量化技术对模型进行降显存处理,同时结合多GPU分布式加载,将17B规模的大模型成功加载到3张H200 GPU上,彻底解决显存瓶颈;
  2. 第三方库兼容问题:发现Transformers库最新版本的嵌入不匹配bug后,选择固定4.51.0版本进行安装,从根源上解决模型加载的兼容性问题,保证项目顺利开展;
  3. 大模型微调算力成本过高问题:选用云GPU平台按需搭建训练环境,避免了专业GPU服务器的高额采购成本,将整体微调成本控制在极低水平,同时支持多GPU灵活配置,满足大模型训练需求;
  4. 通用模型行业适配性差问题:针对医疗推理场景设计专属的Prompt工程,结合医疗专业数据集开展SFT有监督微调,让通用大模型快速具备垂直领域的专业推理能力,大幅提升模型的行业适配性;
  5. 模型训练效率低问题:采用LoRA低秩适配技术,冻结基础模型绝大部分参数,仅训练少量低秩矩阵参数,将模型训练时间压缩至7分钟,大幅提升大模型微调效率。

总结

本文基于实际的客户咨询项目,详细拆解了如何通过云GPU平台实现Llama 4 Scout大模型的低成本、轻量化微调,通过4-bit量化、LoRA低秩适配、多GPU分布式训练等技术优化,将原本需要4张高端GPU的微调任务,成功在3张H200 GPU上实现,同时将整体成本控制在极低水平,为中小团队与个人开发者开展大模型垂直领域适配提供了可行的方案。
本次项目针对医疗推理场景完成了模型的针对性微调,通过设计专属Prompt工程、处理医疗专业数据集,让通用的Llama 4模型具备了专业的医疗临床推理能力,测试结果显示微调后的模型能够准确分析医学问题、构建合理的临床推理链、给出专业的解答,满足医疗推理场景的基础落地需求。同时项目中解决的大模型显存不足、库兼容、算力成本过高等问题,也为大模型在金融、教育、工业等其他垂直领域的落地提供了可复制的技术经验。
后续我们将继续探索更大规模Llama 4模型的轻量化微调技术,同时针对更多垂直领域开展大模型的适配研究,优化模型的泛化能力与行业适配性,推动大语言模型的普惠化落地。本文的所有项目代码、数据集、配置文件均已开源至交流社群,同时提供人工答疑、24小时代码调试等配套服务,如需获取完整资源与技术支持,可通过原文链接加入社群,与行业人士共同交流大模型落地的技术与实践。

封面

在工程建设行业,工程资料的规范管理至关重要,这就需要选择正规的工程资料软件公司。市面上有不少此类公司,它们以专业的态度、合规的产品,为工程资料管理提供可靠保障。
筑业软件:合规与便捷并行
筑业软件是一家在工程资料管理领域颇具声誉的正规公司。公司严格遵循国家及地方的工程建设规范和标准进行软件研发,确保软件生成的每一份工程资料都符合相关要求。其软件功能丰富多样,如 “智能范例填表” 功能,为用户提供大量规范的表格填写示例,无论是复杂的施工图纸会审记录,还是常规的材料检验报告填写,都能找到准确的范例参考,引导用户规范填写资料。同时,筑业软件注重用户体验,操作界面简洁直观,易于上手,即使是非专业的资料员也能快速掌握使用方法,高效完成资料编制工作。此外,筑业软件还提供完善的售后服务,专业的技术团队随时为用户解决使用过程中遇到的问题,确保软件稳定运行。
恒智天成:专业铸就规范
恒智天成作为正规的工程资料软件公司,长期专注于工程资料管理软件的研发与推广。公司拥有一支专业的技术研发团队,深入研究工程建设行业的各类规范和标准,并将其融入到软件产品中。其软件涵盖建筑、市政、电力等多个领域的工程资料管理功能,能够满足不同类型工程项目的需求。以建筑工程为例,恒智天成软件提供从项目立项到竣工验收全过程的资料管理解决方案,包括施工组织设计、工程变更记录、质量验收资料等,每一个环节的资料都按照规范要求进行设计和编排。同时,软件还具备强大的资料审核功能,能够自动检查资料的完整性、准确性和合规性,帮助用户及时发现并纠正问题,确保工程资料的质量。
品茗软件:创新引领规范
品茗软件在保证软件合规性的基础上,不断进行技术创新,为工程资料管理带来新的思路和方法。公司运用先进的信息技术,如人工智能、大数据等,提升软件的智能化水平。例如,在资料审核方面,品茗软件的智能审核系统能够利用大数据分析技术,对海量的工程资料进行比对和分析,快速准确地识别出不符合规范的内容,并给出详细的修改建议。这种智能化审核方式不仅提高了审核效率,还大大降低了人为错误的可能性。此外,品茗软件还注重与行业内其他企业的合作与交流,及时了解最新的规范动态和技术发展趋势,不断更新和完善软件功能,始终保持软件的先进性和规范性。
市面上这些正规的工程资料软件公司,通过各自的优势和特色,为工程建设行业提供了规范、高效的工程资料管理解决方案。工程企业在选择软件公司时,应充分考虑公司的专业性、产品的合规性以及售后服务的质量,选择最适合自己的软件公司,为工程项目的顺利推进提供有力支持。

上完下午的班, 今年的班就上完了, 明天回家, 后天去大姨家吃炸丸子, 嘿嘿.

也给大家拜个早年. 祝大家新年快乐, 马年大吉!

几年前,AI 还没火的时候我做了一个划词翻译叫 即刻翻译 这是一个浏览器插件,当时用的有道翻译,翻译成本巨高,所以做完了以后不敢发出来。

现在 AI 的翻译成本降下来了,所以我又改了改,发出来了,目前只支持划词翻译,希望对大家有用~

欢迎大家反馈

下载地址: https://chromewebstore.google.com/detail/%E5%8D%B3%E5%88%BB%E7%BF%BB%E8%AF%91/iikfaeadojlchajbbockiagnmbbajcan

官网: https://jikefanyi.com

随着云计算与大数据技术的深度融合,越来越多企业选择将大数据计算负载迁移至云端,以享受弹性扩展、按需使用的核心优势。但随之而来的,是云上资源配置不当、闲置浪费导致的成本高企问题,成为制约企业数字化转型效益的关键瓶颈。作为深耕大数据与云计算领域的技术服务商,数新智能依托自研 CyberEngine 产品,构建了一套通过资源优化实现云上大数据计算降本增效的标准化能力,无需定制开发即可适配各类企业场景,本文将深度拆解其核心产品化策略与实践逻辑。

图片

EMR 集群智能调度破解资源闲置困局

针对企业使用亚马逊云科技 EMR(Elastic MapReduce)集群时常见的 “任务集中、资源长期闲置” 痛点,CyberEngine 通过支持 “动态调度 + Serverless 协同” 的技术方案,按需配置和拉起集群,开箱即用,无需额外定制开发,即可实现资源供给与业务需求的精准匹配:

EMR 集群动态拉起与释放: 基于产品原生支持的 SDK 适配能力,CyberEngine 可自动识别业务任务的时间特性(如凌晨 0 点至 4 点高峰期),在任务启动前自动拉起 EMR 集群,执行完毕后立即关闭,从源头杜绝非工作时段的资源闲置浪费,全程无需人工干预。

EMR Spark Serverless 弹性承接: 针对高峰期过后的零散任务,CyberEngine 可自动将其路由至 EMR Spark Serverless 架构。产品已提前完成 EMR 与 Serverless 架构的跨层对接适配,无需企业额外开发,相较于传统常驻 EMR 集群,按实际计算量计费的模式可显著降低非高峰时段资源成本。

数新智能凭借成熟的云原生技术栈,成功解决了EMR与Serverless架构的优势融合问题,同时也发现不同云厂商SDK差异较大的行业痛点。目前该能力已实现产品化,无论企业的 EMR 集群规模、任务时段如何,均可直接启用,轻松解决不同场景下的 EMR 成本浪费问题。

图片

Kubernetes 全云适配解锁跨平台降本潜力

为解决跨云厂商对接复杂、成本可控性差的行业痛点,CyberEngine 已将基于 Kubernetes(K8s)的全云适配资源调度方案完全产品化,凭借 K8s 在亚马逊云科技、Azure、GCP、阿里云、华为云等主流云厂商的统一适配性,为企业提供标准化的跨云资源管理能力,大幅降低平台对接成本的同时,进一步挖掘降本空间。

图片

核心组件集成:Karpenter 赋能极致调度效率

CyberEngine 深度集成亚马逊云科技开源的自动化扩缩容工具 Karpenter,将其核心优势转化为产品化调度能力,实现计算成本的再优化,三大核心产品特性直接适配企业实际需求:

图片

01 Spot EC2 实例智能适配,硬件成本直降二到七成

CyberEngine 内置实例选择策略配置模块,可一键开启 “优先使用 Spot EC2 实例” 模式。这类通过竞价获取的实例,成本仅为按需实例的 20%-70%,产品会自动对任务类型进行精准分类,将 Spark Executor 等非核心、可容错负载定向调度至 Spot 实例,在保障业务稳定性的前提下,实现成本大幅下降。

02 分钟级扩缩容响应,精准匹配业务波动

相较于传统 Cluster Autoscaler,CyberEngine 集成的 Karpenter 组件扩缩容响应速度提升数倍,产品可实时感知业务负载变化,快速调整集群节点规模。无论是电商大促的突发流量峰值,还是日常业务的负载波动,均能在分钟级完成集群扩容,峰值过后迅速缩容,避免资源过度预留浪费。

03 多维度标准化调度规则,适配复杂场景

CyberEngine 内置 “任务优先级 - 资源规格 - 成本预算” 三位一体的标准化调度规则,支持根据节点类型、可用区、资源规格等多维度因素自动调整,无需企业额外定制,即可精准匹配不同业务任务的资源需求,实现资源利用效率与成本控制的最优平衡。

产品内置组件对比:Cluster Autoscaler (CA) vs Karpenter

CyberEngine 提供两种资源调度组件供企业选择,以下为产品内置的标准化对比维度,帮助企业根据自身场景快速决策:

图片

Karpenter 是一个更智能、更快速、更云原生的现代化替代方案,而 Cluster Autoscaler 则是一个更传统和保守的选择。如果您的集群运行在公有云,并且希望降低成本和简化运维,Karpenter 通常是更好的选择。

Karpenter 作为 CyberEngine 推荐的现代化调度组件,更适配公有云场景下的成本优化与运维简化需求,无需额外开发即可享受其核心优势。

CyberEngine 核心价值 标准化产品,全链路降本能力

云上大数据计算的成本优化并非简单的 “降配减容”,而是基于场景适配的标准化资源匹配、高效调度与跨云适配能力的综合体现。数新智能将多年实战经验沉淀为 CyberEngine 产品化能力,无需定制开发,即可为企业提供 “EMR 动态调度”和“Kubernetes + Karpenter”的一体化降本方案,全链路覆盖企业需求。

图片

在数字化转型进入 “降本增效” 关键阶段的当下,数新智能通过 CyberEngine 产品化能力,让企业无需投入定制开发成本,即可享受云上大数据计算的成本优化红利。如果你的企业正面临云上大数据计算成本高企的问题,欢迎体验 CyberEngine 标准化降本方案,让技术赋能成本与效益的最优平衡。

一:参考资料

工行支付SDK:https://open.icbc.com.cn/icbc/apip/docs_sdk&demo.html

工行支付资料:https://download.csdn.net/download/huaweichenai/92636164

PHP对接工行支付组件:https://download.csdn.net/download/huaweichenai/92636166

二:支付详解

1.支付地址

https://gw.open.icbc.com.cn/api/cardbusiness/qrcode/qrgenerat...

2.支付参数

app_id:APP的编号,应用在API开放平台注册时生成

msg_id:消息通讯唯一编号,每次调用独立生成,APP级唯一

format:请求参数格式,仅支持json

charset:字符集 ,缺省为UTF-8

sign_type:签名类型,本接口为RSA2-RSAWithSha256认证方式,为RSA2

sign:报文签名

timestamp:交易发生时间戳,yyyy-MM-dd HH:mm:ss格式

biz_content:请求参数的集合

请求参数

mer_id:商户线下档案编号

out_trade_no:商户系统订单号

order_amt:订单总金额 单位:分

trade_date:商户订单生成日期 yyyyMMdd

trade_time:商户订单生成时间 HHmmss

pay_expire:二维码有效期 单位:秒,必须小于24小时

notify_url:商户接收支付成功通知消息URL

tporder_create_ip:商户订单生成的机器IP

sp_flag:扫码后是否需要跳转分行 0:否,1:是,默认值0

notify_flag:商户是否开启通知接口 0-否;1-是,默认值0

3.签名生成逻辑

(1)签名原文构造

  • 获取所有请求参数,不包括字节型参数,如文件、字节流,剔除sign字段。
  • 将筛选的参数按照第一个字符的键值ASCII码递增排序(字母升序排序),如果遇到相同字符则按照第二个字符的键值ASCII码递增排序,以此类推。
  • 将排序后的参数与其对.值,组合成“参数=参数值”的格式,并且把这些参数用&字符连接来,此时生成的字符串为待签名字符串。

签名原文示例:

/api/cardbusiness/qrcode/qrgenerate/V1?app_id=XXX&biz_content={"mer_id":"XXX","out_trade_no":"XXX","order_amt":"1","trade_date":"20260206","trade_time":"095241","pay_expire":"3600","notify_url":"XXX","tporder_create_ip":"127.0.0.1","notify_flag":"1"}&charset=UTF-8&format=json&msg_id=XXX&sign_type=RSA2&timestamp=2026-02-06 09:52:41

(2)签名生成

将待签名字符串进行RSA2签名,这里以PHP为例如下:

$privateKey = '提供的签名私钥';
$data = '待签名字符串';
$privateKey = str_replace(["\r", "\n", " "], '', $privateKey);
$privateKey "-----BEGIN PRIVATE KEY-----\n".$privateKey."\n-----END PRIVATE KEY-----";
$success = openssl_sign($data, $signature, $privateKey, OPENSSL_ALGO_SHA256);
if (!$success) {
    echo '签名失败';
    exit();
}
$signature = base64_encode($signature);

4:接口调用demo示例

$bizContent = [
    'mer_id' => 'xxx',//商户线下档案编号
    'out_trade_no' => 'xxx',//商户系统订单号
    'order_amt' => '1,//金额 单位:分
    'trade_date' => '20260206',//商户订单生成日期
    'trade_time' => '100101',//商户订单生成时间
    'pay_expire' => '3600',//二维码有效期
    'notify_url' => 'http://www.test.com',//商户接收支付成功通知消息URL
    'tporder_create_ip' => '127.0.0.1',//商户订单生成的机器IP
    'sp_flag' => '0',//扫码后是否需要跳转分行
    'notify_flag' => '1',//商户是否开启通知接口
];

$requestData = [
    'app_id' => 'xxx',//APPID
    'msg_id' => 'xxx',//消息通讯唯一编号
    'format' => 'json',//请求参数格式
    'charset' => 'UTF-8',//字符集
    'sign_type' => 'RSA2',//签名类型
    'timestamp' => '2026-02-06 10:01:01',
    'biz_content' => json_encode($bizContent, JSON_UNESCAPED_UNICODE),
];

//签名
$requestData['sign'] = 'xxx';//签名


$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, '接口地址');
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($requestData));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
// 生产环境开启SSL验证
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
curl_setopt($ch, CURLOPT_TIMEOUT, 30);
curl_setopt($ch, CURLOPT_HTTPHEADER, [
    'Content-Type: application/json',
]);

$response = curl_exec($ch);
$httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
if (curl_errno($ch)) {
    throw new \Exception("HTTP请求失败:" . curl_error($ch));
}
curl_close($ch);

return $response;

作者:David Ducos,Percona 团队 DBA。

原文:https://www.percona.com/blog/rebuilding-a-replica-with-mydumper/

1. 什么是 MyDumper?

当副本因损坏或漂移而失效时,如果无法使用 pt-table-sync,标准解决方案是从主数据库的全新副本重建副本。传统上,为了快速重建副本,我们会使用 物理备份,但在某些情况下,逻辑备份仍然必不可少。例如,当您迁移到特定供应商(例如:从 MariaDB 迁移到 MySQL)或存储引擎(过去是从 MyISAM 迁移到 InnoDB,现在是从 InnoDB 迁移到 RocksDB)、升级到新的数据库版本或迁移到云端解决方案时。

逻辑备份 正是在这种情况下发挥作用,它提供了可移植性和简易性,但前提是能够快速执行。MyDumper 应运而生,成为一款必不可少的现代化解决方案,它兼具两者的优势:逻辑转储的跨平台、跨版本灵活性,以及以往只有物理方法才能实现的并行、多线程速度,使其成为快速重建一致性副本的理想之选。

2. 备份

第一步是进行备份。mydumper 有多个参数可供使用,本例中我们将使用以下参数:

mydumper -v 4 -o data --clear 
--regex '^(?!(mysql.|sys.))' 
--source-data

前 3 行与日志记录和备份目录有关,第二行用于忽略 mysqlsys 模式,最后 –source-data 将指示 mydumper 将恢复后复制配置所需的所有信息保存到元数据文件中,位于 [source] 部分。

以下是输出示例:

[source]
# Channel_Name = '' # It can be used to setup replication FOR CHANNEL
# SOURCE_LOG_FILE = "binlog.000020"
# SOURCE_LOG_POS = 6803936
#SOURCE_HOST = "172.17.0.3"
#SOURCE_PORT =
#SOURCE_USER = ""
#SOURCE_PASSWORD = ""
#SOURCE_SSL = {0|1}
executed_gtid_set = "941fdce6-47c4-11f0-87b2-0242ac110006:1-52"
SOURCE_LOG_FILE = "binlog.000020"
SOURCE_LOG_POS = 6803936
#SOURCE_AUTO_POSITION = {0|1}
myloader_exec_reset_replica = 0
myloader_exec_change_source = 0
myloader_exec_start_replica = 0

如图所示,这些选项已启用:

executed_gtid_set = "941fdce6-47c4-11f0-87b2-0242ac110006:1-52"
SOURCE_LOG_FILE = "binlog.000020"
SOURCE_LOG_POS = 6803936

但是,这些命令的执行已被禁用:

myloader_exec_reset_replica = 0
myloader_exec_change_source = 0
myloader_exec_start_replica = 0
We can enable them, if we set --source-data=7, then the metadata will change to:
myloader_exec_reset_replica = 1
myloader_exec_change_source = 1
myloader_exec_start_replica = 1

这是自动配置复制所必需的。

3. 配置复制

默认情况下将使用 SOURCE_LOG_FILESOURCE_LOG_POS,但如果您配置 SOURCE_AUTO_POSITION = 1,则可以设置 GTID 位置。

如您所知,要设置复制,我们需要执行 CHANGE SOURCE 命令。但是,根据您的具体使用情况,您可能需要执行 RESET REPLICA 命令,并且在执行 CHANGE SOURCE 命令后,通常需要执行 START REPLICA 命令。如果您在元数据文件中使用以下方式进行设置,myloader 可以自动完成此操作:

myloader_exec_reset_replica = 1
myloader_exec_change_source = 1
myloader_exec_start_replica = 1

或者,您可以在 myloader 中使用 --source-data=7 作为参数。是的!myloader 也接受 --source-data 参数。

根据您的使用场景,您可能需要在元数据文件中配置以下其他选项:

#SOURCE_HOST = "172.17.0.3"
#SOURCE_PORT =
#SOURCE_USER = ""
#SOURCE_PASSWORD = ""
#SOURCE_SSL = {0|1}
executed_gtid_set = "941fdce6-47c4-11f0-87b2-0242ac110006:1-52"
SOURCE_LOG_FILE = "binlog.000020"
SOURCE_LOG_POS = 6803936
#SOURCE_AUTO_POSITION = {0|1}

由于存在多种使用场景,如果您想从头开始重建副本,则需要按如下方式配置:

[source]
SOURCE_HOST = "172.17.0.3"
SOURCE_PORT = 3306
SOURCE_USER = "replica"
SOURCE_PASSWORD = "r3pl1c4"
executed_gtid_set = "941fdce6-47c4-11f0-87b2-0242ac110006:1-52"
SOURCE_LOG_FILE = "binlog.000020"
SOURCE_LOG_POS = 6803936
myloader_exec_reset_replica = 1
myloader_exec_change_source = 1
myloader_exec_start_replica = 1

如果您已经建立了一个正在运行的复制系统,并且想要在不更改主机或凭据的情况下重建它,那么您可以按以下方式进行配置:

[source]
executed_gtid_set = "941fdce6-47c4-11f0-87b2-0242ac110006:1-52"
SOURCE_LOG_FILE = "binlog.000020"
SOURCE_LOG_POS = 6803936
myloader_exec_reset_replica = 0
myloader_exec_change_source = 1
myloader_exec_start_replica = 1

SSL 是 myloader--source-data 参数可以设置的另一个选项,无需在元数据文件中使用 SOURCE_SSL。完整的选项列表如下:exec_start_slave (1)exec_change_master (2)exec_reset_slave (4)SSL (8)auto_position (16)exec_start_replica_until (32)。根据您要设置的配置和要执行的语句,您需要将这些值相加,并将其传递给 --source-data 参数。

4. 恢复

配置好元数据文件后,即可执行 myloader,其界面如下所示:

myloader -d data -v 4 
-o --max-threads-for-schema-creation=1 
-h replica_host

在日志中,你会发现 myloader 发送了以下命令:

2025-12-18 16:57:09 [INFO] - Schema create checksum confirmed for sakila
2025-12-18 16:57:09 [INFO] - Sending reset replica
2025-12-18 16:57:09 [INFO] - Sending change replication source
2025-12-18 16:57:09 [INFO] - Sending start replica
2025-12-18 16:57:09 [INFO] - Restore completed

mydumper 会发送命令,但不会检查输出,这意味着如果复制配置失败或无法启动,您需要手动检查并修复。但是,它会检测到命令是否失败,例如,如果使用了 SOURCE_USER 而不是 SOURCE_USER

2025-12-18 17:02:56 [WARNING] - Sending replication command: CHANGE REPLICATION SOURCE TO SOURCE_HOST = "172.17.0.4", SUORCE_USER = "root", SOURCE_PASSWORD = "", SOURCE_LOG_FILE = "binlog.000020", SOURCE_LOG_POS = 1362220 FOR CHANNEL ''; - ERROR 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'SUORCE_USER = "root", SOURCE_PASSWORD = "", SOURCE_LOG_FILE = "binlog.000020", SO' at line 1

5. 对故障副本进行重建

有一个有趣的用例,我们可以使用 START REPLICA UNTIL 来修复某些表的偏移,而 pt-table-sync 或重建整个副本是不可能的。

假设我们有一个源数据库和一个副本数据库,我们发现副本数据库上的数据发生了,并且复制过程停止并出现如下错误:

LAST_ERROR_MESSAGE: Worker 1 failed executing transaction 'ANONYMOUS' at source log binlog.000020, end_log_pos 1369103; Could not execute Update_rows event on table test.test_table; Can't find record in 'test_table', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's source log binlog.000020, end_log_pos 1369103

我们检查了二进制日志,发现它因对一组行进行更新而失败:

# at 1368995
#251218 19:34:59 server id 1 end_log_pos 1369103 CRC32 0x60a481d6 Update_rows: table id 344 flags: STMT_END_F
### UPDATE `test`.`test_table`
### WHERE
### @1=12 /* INT meta=0 nullable=0 is_null=0 */
### @2=7062 /* INT meta=0 nullable=1 is_null=0 */
### SET
### @1=12 /* INT meta=0 nullable=0 is_null=0 */
### @2=7063 /* INT meta=0 nullable=1 is_null=0 */
### UPDATE `test`.`test_table`
### WHERE
### @1=15 /* INT meta=0 nullable=0 is_null=0 */
### @2=7521 /* INT meta=0 nullable=1 is_null=0 */
### SET
### @1=15 /* INT meta=0 nullable=0 is_null=0 */
### @2=7522 /* INT meta=0 nullable=1 is_null=0 */
### UPDATE `test`.`test_table`
### WHERE
### @1=17 /* INT meta=0 nullable=0 is_null=0 */
### @2=8706 /* INT meta=0 nullable=1 is_null=0 */
### SET
### @1=17 /* INT meta=0 nullable=0 is_null=0 */
### @2=8707 /* INT meta=0 nullable=1 is_null=0 */
### UPDATE `test`.`test_table`
### WHERE
### @1=18 /* INT meta=0 nullable=0 is_null=0 */
### @2=8108 /* INT meta=0 nullable=1 is_null=0 */
### SET
### @1=18 /* INT meta=0 nullable=0 is_null=0 */
### @2=8109 /* INT meta=0 nullable=1 is_null=0 */
# at 1369103

我们检查了数据库,发现数据确实发生了偏移:

源端

mysql> select count(*) from test.test_table;
+----------+
| count(*) |
+----------+
| 15 |
+----------+
1 row in set (0.00 sec)

副本

mysql> select count(*) from test.test_table;
+----------+
| count(*) |
+----------+
| 14 |
+----------+
1 row in set (0.00 sec)

使用 MyDumper,我们可以按照以下步骤重建表:

我们需要忽略该表,以便副本能够赶上进度。

mysql-replica> STOP REPLICA;
Query OK, 0 rows affected (0.00 sec)

mysql-replica> CHANGE REPLICATION FILTER REPLICATE_IGNORE_TABLE= (test.test_table);
Query OK, 0 rows affected (0.00 sec)

mysql-replica> START REPLICA;
Query OK, 0 rows affected (0.00 sec)

副本更新完成后,我们需要停止副本:

mysql-replica> STOP REPLICA;
Query OK, 0 rows affected (0.00 sec)

并对源服务器进行备份:

mydumper -v 4 -o data --clear 
-T test.test_table 
--source-data

我们使用 -T 来备份有问题的表,而 –source-data 将启用我们需要的元数据文件上的复制变量。

然后,我们使用正确的值通过 --source-data 参数恢复表。

myloader -d data -v 4 
-o --max-threads-for-schema-creation=1 
-h replica_host 
--source-data=32

第 32 行是执行 START REPLICA UNTIL

最后,我们移除忽略表选项并重新启动副本:

mysql-replica> CHANGE REPLICATION FILTER REPLICATE_IGNORE_TABLE= ();
Query OK, 0 rows affected (0.00 sec)

mysql-replica> START REPLICA;
Query OK, 0 rows affected (0.00 sec)

myloader 在备份开始时执行的 START REPLICA UNTIL 将强制副本在备份表的位置停止,从而使我们能够在一致的场景中继续复制。

6. 结论

从传统的数据转储方法转向 MyDumper 不仅仅意味着性能的提升,更代表着数据完整性和迁移性的现代化。通过将备份过程从单线程执行的限制中解耦,数据库管理员现在可以像以往处理小型测试环境一样灵活地处理海量数据集。

MyDumper 集成到您的标准操作手册中,可确保您能够应对各种不可预测的情况 —— 无论是紧急副本重建还是计划内的架构迁移。在数据量持续呈指数级增长的时代,拥有一款兼具逻辑灵活性和并行速度的工具至关重要,而 MyDumper 正是这样一款工具。将其保留在您的工具箱中,下次遇到“仅逻辑恢复”场景时,您将拥有显著的竞争优势。

Python是一种功能强大的编程语言,其简洁的语法和丰富的标准库使得它成为快速搭建Web服务的理想工具。

本文将引导您从零开始,通过Python内置模块搭建本地Web服务,并结合 ZeroNews 实现远程访问。

一、 安装Python并运行本地服务

环境准备
安装Python服务
实现一个本地 web.py 本地服务

1. 首先在Python官网下载python服务
图片

2. 下载完成后,根据步骤安装即可3. 安装完成过后,我们可以通过命令检查我们的python是否安装成功。
图片

图片

4. 看到上述出现对应的版本,就表示安装成功了5. 接下来,我们进入到我们Web本地服务的文件夹,例如 D:\Download\zeronews\python
图片

5. 小编搭建了一个比较简单的 web服务(仅供参考,可以替换成自己的web服务项目)
图片

图片

  1. 然后我们打开cmd窗口,并通过命令进入到web服务文件夹中
    图片

图片

7. 然后通过python运行我们的本地服务
图片
httpserver.py 为我们本地服务运行的文件
图片

8. 运行成功后,可以看到服务已经启动,可以通过浏览器访问以下地址:Web界面:127.0.0.1:8000
图片

接下来,我们可以通过 ZeroNews 服务,将我们的web服务映射到公网访问

二、 创建 ZeroNews 映射服务

打开 ZeroNews 网站,然后选择您的系统(小编用的是用Win10,选择Windows即可),并按照对应的步骤和命令安装运行 Agent 服务。

注意:
Agent 前台运行不能关闭命令窗口
如果您想要开机自启动,可以执行后台运行命令

图片

图片

图片

图片

1. 运行完成之后,您可以在 Agent 页面看到已经在线的 Agent 服务。
图片

2. 接着,我们在域名端口页面,创建一个可用的公网域名(自定义前缀),并勾选HTTPS 协议端口。
图片

3. 域名创建完成之后,我们继续打开映射页面,并按下面的步骤添加映射
Agent:选择第一步运行的 Agent
映射协议:选择 HTTPS 协议
域名:选择刚创建好的域名
带宽:根据需要选择带宽大小
内网IP:我们是本地部署,直接使用 127.0.0.1 即可
内网端口:输入本地服务的端口 8000 即可
图片

4. 照上述步骤创建完成之后,我们就可以得到一条可公网访问的映射域名
图片

三、 公网访问您的web本地服务

我们在任意有网络访问电脑的浏览器上,复制上面的链接并打开访问我们的本地服务了。
图片

Astro,一个用于构建内容驱动型网站的 Web 框架,已经宣布了Astro 6 Beta版本,引入了一个完全重新设计的开发服务器、一流的 Cloudflare Workers 支持,以及几个新的稳定 API,包括实时内容集合和内容安全策略支持。

 

Astro 6 Beta 版对开发人员使用该框架的方式带来了重大改变,包括基于 Vite 的Environment API重构的开发服务器、用于实时数据更新的稳定实时内容集合,以及内置的 CSP 支持。该版本还包括一些重大的破坏性变更,如需要使用 Node 22+并移除几个弃用的 API。

 

Astro 6 中的一大特性是完全重新设计的astro dev开发服务器。新服务器利用 Vite 的 Environment API 在与生产环境相同的运行时中运行应用程序,缩小了开发和部署环境之间的差距。以前,在本地工作的代码一旦部署可能会有不同的行为,而且平台特定的特性通常在部署后才能测试。通过统一开发和生产代码路径,Astro 团队已经发现并修复了许多仅存在于开发或仅存在于生产中的微妙错误。

 

新的开发服务器使之成为可能的最完整的例子是对 Cloudflare Workers 的支持。有了 Astro 6 Beta,astro dev现在可以使用 workerd 运行应用程序,这是 Cloudflare 的开源 JavaScript 运行时,这与在生产环境中支持 Cloudflare Workers 的运行时相同。这意味着开发者现在可以直接针对真实的平台 API 进行开发,而不是模拟或 polyfills。当使用 Cloudflare 支持运行astro dev时,开发者现在可以访问 Durable Objects、KV Namespaces、R2 Storage、Workers Analytics Engine 和环境变量,所有这些都支持热模块替换。

 

现在可以直接使用cloudflare:workers模块访问 Cloudflare 绑定,如 beta 博客文章所示:

 

import { env } from "cloudflare:workers"; const kv = env.MY_KV_NAMESPACE; await kv.put("visits", "1"); const visits = await kv.get("visits");
复制代码

 

在 Astro 5.10 中还在试验性的实时内容集合,现在在 Astro 6 中已经稳定。这些建立在 Astro 的类型安全内容集合之上,可以实时更新数据,而不需要重新构建,这使得它们非常适合频繁更新数据源,如实时股票价格或库存。该 API 旨在让已经使用 Astro 的构建时内容集合的人感到熟悉,但对实时数据请求的实际情况进行了显式的异常处理。

 

内容安全策略支持,之前在 Astro 5.9 中是实验性的,现在已经稳定。CSP 是 Astro 获得最多投票的特性请求,它有助于保护网站免受跨站脚本和其他代码注入攻击。该功能在所有 Astro 渲染模式中工作,并与所有官方适配器兼容,自动生成 CSP 头或元元素,包括脚本和样式的哈希。

 

Astro 6 包括几个重大破坏性变更,因为团队清理了弃用的 API。最重要的变化包括移除Astro.glob(),要求 Node 22 或更高版本,以及更新 Cloudflare 适配器,移除Astro.locals.runtime,转而直接访问平台 API。团队已经发布了一个全面的升级指南,详细说明了每个破坏性变更的迁移步骤。

 

该版本在社区内引发了一些讨论,reddit 上的一位用户对长长的破坏性变更列表发表了评论(特别提到了早期的 alpha 版本):

 

哇。真是一个巨大的破坏性变更列表……

 

这引起了 Astro 核心维护者Sarah Rainsberger的回应:

 

大多数变更至少不会影响每个人!

 

她继续解释了有这样一个详细的破坏性变更列表的理由:

 

……我坚信,任何可能破坏某人项目的东西都应该包含在这一页上……无论那个“项目”是一个常规的静态网站,还是你构建的主题,或者一个复杂的集成。

 

Hacker News上,评论者强调 Astro 是最早支持 Cloudflare 的 Vite 插件的框架之一:

 

Cloudflare 发布了他们的 vite 插件,使得使用 vite env API 的框架可以毫不费力地在 workerd 中运行……Nextjs 还没有支持,添加对 Sveltekit 支持的草案 PR 已经被搁置,直到下一个主要版本,Astro 刚刚在他们 3 天前的 beta 6.0 版本中添加了支持。

 

与其他元框架如Next.js和 SvelteKit 相比,Astro 以其专注于内容驱动型网站和默认最小化客户端 JavaScript 而脱颖而出。Next.js 强调 React 和全栈能力,SvelteKit专注于 Svelte 生态系统,而 Astro 仍然与框架无关,通过其孤岛架构官方支持ReactVueSvelte和其他 UI 框架。

 

Astro 是一个开源 Web 框架,旨在构建包括博客、营销网站和电子商务在内的内容驱动型网站。该框架通过最小化客户端 JavaScript,尽可能在构建时或按需在服务器上渲染内容,强调性能。

 

原文链接:

https://www.infoq.com/news/2026/02/astro-v6-beta-cloudflare/

Cloudflare 最近分享了他们是如何使用SaltStack(Salt)管理庞大的全球服务器集群的。在这篇博客文章中,他们讨论了解决“一粒沙(grain of sand)”问题所需的工程任务。它的关注点在于要从数百万次状态应用中找出某个配置错误。Cloudflare 的站点可靠性工程(SRE)团队重新设计了其配置的可观测性,他们将故障与部署事件关联起来。这项工作将发布延迟减少了 5%以上,并减少了手动分析问题相关的工作。

 

作为配置管理(configuration management,CM)的工具,Salt 能够确保了跨数百个数据中心的数千台服务器保持在期望的状态。在 Cloudflare 的规模下,即使 YAML 文件中的一个微小语法错误或“Highstate”运行期间的瞬时网络故障,都可能阻碍软件发布。

 

Cloudflare 面临的主要问题是预期配置与实际系统状态之间的“偏离(drift)”。当 Salt 运行失败时,它影响的不仅仅是一台服务器,它可能会阻止在整个边缘网络中推出关键的安全补丁或性能特性。

 

Salt 使用了带有ZeroMQ主控/受控(master/minion)设置。这使得很难找出为什么特定的受控端(代理)没有向主控端报告状态,这简直就像大海捞针。Cloudflare 总结了几个破坏此反馈循环的常见故障模式:

  1. 无声故障:受控端在状态应用期间可能会崩溃或挂起,导致主控端无限期地等待响应。

  2. 资源耗尽:繁重的 pillar 数据(元数据)查找或复杂的 Jinja2 模板可能会使主控端的 CPU 或内存不堪重负,导致 job 丢失。

  3. 依赖地狱:包状态可能会因为上游仓库无法访问而失败,但错误消息可能埋藏在数千行日志的深处。

Salt 的架构图

 

当发生错误时,SRE 工程师必须手动通过 SSH 登录到候选受控端。他们会追踪主控端上的 job ID,并筛选保留时间内有限的日志,然后尝试将错误与变更或环境条件联系起来。在拥有数千台机器和频繁提交代码的情况下,这个过程变得单调且难以维护。它提供的持久工程价值非常有限。

 

为了解决这些挑战,Cloudflare 的商业智能和 SRE 团队合作构建了一个新的内部框架。目标是为工程师提供一种“自助服务”机制,以识别跨服务器、数据中心和特定机器组的 Salt 故障的根本原因。

 

解决方案涉及从集中式日志收集转向更健壮的、事件驱动的数据摄入管道。这个在相关内部项目中被称为“Jetflow”的系统,允许将 Salt 事件与以下内容关联:

  • Git 提交:识别配置仓库中触发故障的精确变更。

  • 外部服务故障:确定 Salt 失败是否实际上是由依赖项(如 DNS 故障或第三方 API 中断)引起的。

  • 临时(Ad-Hoc)发布:区分计划的全局更新和开发人员进行的手动更改。

 

Cloudflare 通过改变管理基础设施故障的方式,为自动分类奠定了基础。系统现在可以自动标记特定的“一粒沙”,即导致发布阻塞的那一行代码或那一台服务器。

 

从被动管理到主动管理的转变带来了以下成果:

  • 发布延迟减少 5%::通过更快地暴露错误,缩短了从“代码完成”到“在边缘运行”的时间。

  • 减少琐事:SRE 不再需要花费数小时进行“重复性分类”,使他们能够专注于更高层次的架构改进。

  • 改进的可审计性:现在每个配置变更都可以从 Git PR 到边缘服务器上的最终执行结果进行全生命周期追踪。

 

Cloudflare 工程团队观察到,尽管 Salt 是一个强大的工具,但在“互联网规模”下管理它需要更智能的可观测性。通过将配置管理视为一个需要关联和自动分析的关键数据问题,他们为其他大型基础设施提供商树立了榜样。

 

基于 Cloudflare 在 SaltStack 上遇到的挑战,需要注意的是,像AnsiblePuppetChef这样的替代配置管理工具,每个工具都有不同的架构权衡。Ansible 使用 SSH 无代理的方式工作。这比 Salt 的主控/受控设置更简单。然而,由于顺序执行,它在大规模环境时可能会面临性能问题。Puppet 使用基于拉取的模型,代理会与主控服务器进行核对。这提供了更加可预测的资源使用,但与 Salt 的推送模型相比,可能会减慢紧急变更的速度。Chef 也使用代理,但侧重于使用其 Ruby DSL 的代码驱动方法。这为复杂任务提供了更大的灵活性,但学习曲线更陡峭。

 

在 Cloudflare 的规模下,任何工具都会遇到其自身的“一粒沙”问题。然而,关键教训很明确,那就是管理数千台服务器的任何系统都需要强大的可观测性。它还必须能够将故障与代码变更自动关联,并具备智能分类机制。这将手动侦探工作转化为可操作的洞察力。

 

原文链接:

Cloudflare Automates Salt Configuration Management Debugging, Reducing Release Delays

一、云游戏的 “生死线”:被服务器拖垮的业务痛点

做云游戏 5 年,我们曾因西南地区玩家延迟超 75ms,3 天流失 18% 核心用户;为承载 20 万并发,单月云带宽支出破 15 万,占营收 30%。这并非个例,中国音数协游戏工委数据显示,72% 用户因 “延迟超 50ms” 放弃体验,云游戏服务器托管有三大痛点:

延迟敏感:每增 10ms 延迟,操作失误率升 8%,传统 IDC 单一网络易致跨区域体验崩盘;

带宽刚需:1080P/60 帧单用户需 8-12Mbps,10 万并发需 1T 带宽,扩容成本高、灵活性差会卡业务脖子;

存储算力双高:游戏安装包(平均 50GB / 款)需高速存储,高规格 GPU 服务器对供电、散热要求高,普通机房难满足。

此时,选适配的 IDC 机房成企业生死关键。

二、云游戏选 IDC 的 5 个 “黄金标准”,缺一不可

经 3 个月调研、20 + 机房对比,总结出核心逻辑 —— 围绕 “玩家体验” 与 “成本可控”,这 5 点是硬指标:

标准 1:网络架构 “低延迟优先”,多线 BGP 是基础

云游戏延迟由 “物理距离 + 网络节点” 决定,单一线路易致多运营商用户体验差。适配 IDC 需具备三线 (电信 + 联通 + 移动)。

成都极云科技主机房不仅支持电信、联通、移动单线机房,更有三线 接入,还搭建 “西南 - 华北 - 华东” 骨干网直连通道。我们测试时,西南玩家延迟 28-35ms,华北≤40ms,比云托管降 45%。更可按玩家分布定制带宽配比,避免冗余浪费。

标准 2:带宽 “足量 + 灵活”,扩容成本可控

云游戏带宽有 “潮汐特性”,闲时利用率仅 30%,传统 IDC 固定套餐浪费多、临时扩容需 3-5 天,难应对突发需求。

极云带宽方案破解矛盾:

基础带宽性价比高:100M 独享电信带宽月费 1800 元(18 元 / M / 月),远低于云厂商 50-80 元 / M / 月;

弹性扩容秒级响应:运维平台可实时申请临时扩容(最高 1000M),按小时计费,去年双十一加 500M 带宽 3 小时仅 225 元,省 60%;

流量监控可视化:实时查看分区带宽,可关停低效分区控成本。

标准 3:存储 “高低速分层”,适配游戏数据特性

云游戏热数据(安装包、缓存)需毫秒级响应,冷数据(存档、日志)需大容量,单一存储方案难平衡体验与成本。

极云定制分层存储方案:

热数据区:NVMe SSD 阵列读写 3500MB/s,游戏加载时间从 25 秒压至 8 秒,投诉降 70%;

冷数据区:HDD+zstd 压缩,1000 款游戏存档从 50TB 压至 22TB,成本降 56%;

自动分层调度:按访问频率自动迁移数据,无需人工干预,运维效率升 80%。

标准 4:算力承载 “适配高规格服务器”,供电散热有保障

云游戏依赖高配置 GPU 服务器(如 RTX 4090,单台功耗 800W),普通 IDC 机柜供电(10A)、散热不足易死机。

极云硬件承载优势显著:

高功率机柜:16A/32A 规格,单柜供电 7.68KW,配独立散热,温度稳定 22-25℃;

灵活部署:支持 4U/8U 高密度托管,20 台 GPU 服务器仅占 5 机柜,年省 3.6 万;

硬件兼容:工程师提前对接厂商测兼容性,20 台服务器 2 天完成上架。

准 5:运维 “7×24 小时零中断”,故障响应快

云游戏需全天候服务,1 小时故障或致玩家流失,IDC 运维需快速解决、提前预防。

极云运维让我们放心:

分钟级响应:去年春节机柜电源故障,工程师 12 分钟到场,切换备用电源,中断仅 45 秒(行业平均 30 分钟);

主动巡检:每周 2 次硬件巡检,提前更换 2 块故障 SSD,避数据丢失;

专属对接:1 对 1 运维经理,可按业务节奏(如新版本上线)提前扩容,无需反复沟通。

三、实战效果:托管半年,玩家留存升 20%,成本降 40%

迁移极云半年,业务数据显著改善:

体验端:平均延迟从 62ms 降至 32ms,卡顿率从 15% 降至 3%,核心玩家月留存升 20%,新增次日留存升 12%;

成本端:月均托管成本从 15 万降至 9 万,省 40%(带宽省 52%、存储省 56%、运维人力省 35%);

稳定性端:机房可用性 99.92%(云托管 99.5%),故障从每月 3-4 次降至 0 次。

成都某同行用极云 “IDC + 云弹性扩容” 方案,峰值并发从 10 万升至 30 万,成本仅增 50%,玩家满意度居行业 Top3。

四、结语:云游戏选 IDC,找对 “适配者” 比选 “贵的” 更重要

对云游戏企业,IDC 是业务增长的基础设施,无需盲目追高规格,需找匹配需求(用户分布、带宽波动、服务器配置)的伙伴。成都极云科技懂云游戏,方案围绕核心需求设计,实现 “体验不打折,成本可控制”。

若你正被延迟、带宽、成本困扰,可了解极云机房产品,更多详情访问官网,或咨询云游戏专属解决方案顾问。