梦想博客

PHP使用wkhtmltoimage网页截屏安装使用方法

Tue, 20 Jan 2026 23:18:16 +0800

进入项目目录，执行composer安装：

composer require h4cc/wkhtmltoimage-amd64

CP到全局设置：

Sudo cp vendor/h4cc/wkhtmltoimage-amd64/bin/wkhtmltoimage-amd64 /usr/local/bin/wkhtmltoimage

设置可执行权限：

sudo chmod +x /usr/local/bin/wkhtmltoimage

检测版本：

wkhtmltoimage --version

如果正常的话，显示版本号

wkhtmltoimage 0.12.4 (with patched qt)

优化：

Wkhtmltoimage --javascript-delay 3000 url 存储路径

设置参数 --javascript-delay 3000延迟3秒

简单执行

wkhtmltoimage 网页地址存储路径

功能特性	wkhtmltoimage	传统截图工具	其他命令行方案
启动速度	极快（<100ms）	较慢（3-5秒）	中等（200-500ms）
资源占用	低内存消耗	高资源需求	中等占用
批量处理	原生支持	需额外脚本	有限支持
格式兼容	8种主流格式	基础格式	3-5种格式
自动化集成	完美支持	复杂配置	部分支持

再创历史新高，上海港集装箱吞吐量连续16年位居世界第一

Thu, 08 Jan 2026 21:17:19 +0800

2025年上海港集装箱吞吐量突破5506万标箱，再创历史新高，连续16年位居世界第一。

港区码头里，桥吊依循指令精准起落，全自动无人引导车秩序井然，智能作业管控系统实时调度；海面巨轮旁，甲醇燃料加注和集装箱装卸同步进行，上海港已经实现国产绿色甲醇全产业链供应服务能力；东海大桥上，智能重卡无人驾驶车辆有序行进，打通“东海大桥+集疏运中心+洋山港”全链路……作为上海港的重要组成部分，洋山港在2025年迎来开港20周年，吞吐量再创历史新高。

全国劳动模范、上海洋山四期自动化码头首席远程操作员黄华说：“自动化码头可以24小时全速高效运转，一昼夜能处理超过2.8万标准箱，劳动生产率达到了传统码头的213%。”洋山港海事部门创新实施的全潮水时段“三套泊”作业，平均每次为每艘船舶节省约2小时的船期，提升岸线利用率5%。

据了解，随着小洋山北作业区、罗泾港区集装箱码头改造二期等项目的持续推进，上海港的集装箱吞吐能力还将扩容提效。

编辑：鲁琳

资料：新华社

* 转载请注明来自浦东发布官方微信

程序员薪资等级，看看你在哪个level？

Tue, 02 Dec 2025 10:49:40 +0800

“你说，同样是写代码，为什么有人月薪5000，有人拿50000？”

“这哪是薪资差距，这分明是职业路线的分水岭。”

当这份真实的程序员薪资表摆在面前，那些数字不再是冷冰冰的统计，而是一张张清晰的职业导航图。

从最低5千到最高6.5W，十二倍的差距里，藏着这个行业最残酷的真相。

普通Web前端：中位数12500，最高27500

编译器开发工程师：中位数28083，最高65650

算法工程师：中位数20000，最高46875

普通软件工程师：中位数12500，最高35000

编译器开发工程师的中位数，已经是普通软件工程师最高薪资的1.8倍。这不仅仅是薪资的差距，更是技术深度的鸿沟。

“我做了三年Java开发，月薪18k，以为还不错。”一位在某二线互联网公司工作的朋友说，“直到看到编译器工程师的薪资，我才知道自己在技术食物链的什么位置。”

一位35岁的编译器开发工程师，道出了真相：“很多人以为程序员就是写业务代码，但其实技术分三层：业务实现、系统设计、底层创新。

大多数人在第一层挣扎，少数人进入第二层，极少数人在第三层创造价值。”

这张薪资表，实际上在告诉我们一个残酷的现实：你的薪资不取决于你有多努力，而取决于你的技术栈有多“深”。

浅水区（月薪1.2万-1.8万）

Web前端、移动开发、Unity3D

特征：技术更新快，门槛相对低，竞争激烈

深水区（月薪2万-3万）

算法工程师、架构师、深度学习

特征：需要深厚理论基础，技术壁垒高

深海区（月薪3万-6.5万）

编译器开发、核心系统架构

特征：需要多年积累，技术门槛极高，不可替代性强

观察数据可以发现，工作3-5年是个关键分水岭。

在这个阶段，选择深耕底层技术的工程师，开始与同龄人拉开差距。

“我在前三年做业务开发，后来毅然转向编译器方向。”

“那两年几乎每天都在啃底层源码，但五年后，我的薪资是同期做业务开发同事的三倍。

为什么你的薪资上不去？

普通软件工程师最高薪资：35000

编译器开发工程师最低薪资：11000

这意味着，一个顶尖的业务开发工程师，还不如一个入门的底层技术工程师。这不是公平问题，而是价值贡献的差异。

业务代码随时可能因产品下线而消失，而底层技术积累却像陈年老酒，越存越香。

当你深夜加班修bug时，是否想过：这行代码，值多少钱？

当你追逐最新框架时，是否思考过：这些表面功夫，能构筑多深的技术护城河？

更重要的是：五年后，你希望自己的简历上写着“精通各种业务开发”，还是“深度参与编译器研发”？

那个随时可被替代的“业务能手”，还是成为那个无可替代的“技术核心”？

当浪潮退去，方知谁在裸泳，当风口消失，才见真本事。

Code Review的真正价值在于在代码进入生产前,用经验和判断力筛选出真正重要的问题

Fri, 10 Oct 2025 09:22:38 +0800

开篇:一个扎心的场景

你花了两天时间精心实现一个功能,提交PR后满怀期待等待Review。结果收到20条评论:

"这个变量名建议改成userData"
"这里用三元运算符更简洁"
"建议把这段提取成独立函数"

你逐条修改,再次提交。然后代码上线了,生产环境炸了——因为并发场景下的race condition没人发现。

这就是大部分团队Code Review的现状:把时间花在不重要的细节上,真正致命的问题却视而不见。

作为一个在前端摸爬滚打多年的老兵,我见过太多这样的场景。今天我想聊聊,真正的高级开发者是怎么做Code Review的——以及为什么他们的方式和你想的完全不同。

第一个颠覆认知:先问"该不该存在",别管"写得好不好"

大部分人的审查顺序是错的

打开一个PR,99%的人第一反应是看代码实现:

变量命名规范吗?
函数拆分合理吗?
有没有遵循最佳实践?

但高级开发者的第一个问题是:这段代码应该存在吗?

我见过一个经典案例。某同学提交了一个完美的虚拟滚动实现,处理了边界情况,写了完整测试,代码优雅得让人想点赞:

// PR标题: 为表格添加虚拟滚动优化性能
function VirtualizedTable({ data, rowHeight = 50 }) {
const [scrollTop, setScrollTop] = useState(0);
const containerHeight = 600;

// 计算可见区域
const visibleStart = Math.floor(scrollTop / rowHeight);
const visibleEnd = Math.ceil((scrollTop + containerHeight) / rowHeight);
const visibleData = data.slice(visibleStart, visibleEnd);

return (
    <div 
      style={{ height: containerHeight, overflow: 'auto' }}
      onScroll={e => setScrollTop(e.target.scrollTop)}
    >
      <div style={{ height: data.length * rowHeight }}>
        <div style={{ transform: `translateY(${visibleStart * rowHeight}px)` }}>
          {visibleData.map(row => <TableRow key={row.id} data={row} />)}
        </div>
      </div>
    </div>
  );
}

代码挑不出毛病。但问题在于:为什么要一次性加载10000条数据?后端API明明支持分页,为什么不用?

虚拟滚动解决的是"如何高效渲染大量DOM"的问题。但真正的问题是"为什么要在前端渲染这么多数据"。这就像你家着火了,你选择买个更好的灭火器,而不是找出起火原因。

真正的Code Review应该质疑解决方案本身,而不是解决方案的实现质量。

这需要跳出代码看问题:

理解业务背景和技术架构
思考有没有更简单的方案
判断这个PR是在解决症状还是病根

这种思维方式,才是高级开发者和普通开发者的分水岭。

第二个颠覆认知:懂得什么不重要,比懂得什么重要更重要

注意力是有限资源,别浪费在无关紧要的地方

我有个controversial的观点:大部分代码细节根本不重要。

变量叫userData还是user? 无所谓
用if-else还是三元运算符? 无所谓
10个元素用.map()还是for循环? 也无所谓

看到这里可能有人要跳起来:"代码质量很重要!细节决定成败!"

我没说代码质量不重要。我是说:注意力是稀缺资源,应该花在刀刃上。

这里有个建筑学的概念很有启发——承重墙和非承重墙。承重墙支撑整个结构,拆了房子就塌;非承重墙只是分隔空间,改了无伤大雅。

代码也一样。有些决策是"承重"的:

影响性能的算法选择
关系到安全的权限设计
决定可维护性的架构方案

这些值得死磕。但更多的是"非承重"的偏好:

// 这三种写法值得你留10条评论吗?

// 写法1
const isValid = data.name && data.email;

// 写法2  
const isValid = Boolean(data.name && data.email);

// 写法3
const hasName = !!data.name;
const hasEmail = !!data.email;
const isValid = hasName && hasEmail;

写法3可读性可能好一点点。但值得让作者改代码、推新commit、延迟功能上线吗?

高级开发者知道什么时候该闭嘴。 不是因为妥协代码质量,而是因为他们清楚:在无关紧要的问题上消耗团队精力,就没时间关注真正重要的事了。

第三个核心技能:预见什么会炸

线上事故都是可以预防的,如果你知道该看哪里

经历过几次生产事故后,你就会形成一种直觉——知道哪些代码模式容易出问题。

最容易被忽视的就是错误处理。 不是"有没有try-catch",而是"出错了会怎样"?

async function getUserProfile(userId) {
  const response = await fetch(`/api/users/${userId}`);
  const data = await response.json();
  return data;
}

这代码开发环境跑得好好的。但上线后:

API返回500怎么办?
响应是HTML错误页而不是JSON怎么办?
网络超时了怎么办?
用户看到的是什么?白屏?报错?还是无限loading?

初级Review可能会说:"加个try-catch吧"。

高级Review会问:"用户体验应该是什么?显示错误提示?重试?用缓存数据?哪种失败模式对用户最友好?"

这才是关键差异——不是检查代码在理想情况下能不能跑,而是思考在最糟糕的情况下用户会遇到什么。

所有系统都会失败。API会挂,网络会断,数据库会超时,第三方服务会返回垃圾数据,用户会做你意想不到的操作。真正的代码审查,是在代码进入生产前,就预见到这些失败场景。

第四个维度:关注PR里没有的东西

最隐蔽的bug往往藏在"没写的代码"里

优秀的Code Review不只看写了什么,更要问:没写什么?

function useUserData(userId) {
  const [data, setData] = useState(null);
  
  useEffect(() => {
    fetchUser(userId).then(setData);
  }, [userId]);
  
  return data;
}

这代码看起来没问题。但高级开发者会问:

"如果userId变化了,但上一个请求还没返回呢?组件会先设置旧数据,再被新数据覆盖吗?"

这就是经典的race condition。用户快速切换tab,页面显示错乱,没人知道为什么。

修复其实很简单,但前提是你要想到去找这个问题:

function useUserData(userId) {
const [data, setData] = useState(null);

  useEffect(() => {
    let cancelled = false;
    
    fetchUser(userId).then(user => {
      if (!cancelled) setData(user);
    });
    
    return() => { cancelled = true };
  }, [userId]);

return data;
}

这类问题需要你在脑子里"运行"代码:

组件卸载时会发生什么?
函数同时执行多次会怎样?
异步操作完成前用户跳转了呢?

线性阅读代码是不够的,你需要在多个维度上模拟执行。 这是经验积累的结果,也是高级开发者最值钱的技能之一。

第五个判断标准:知道什么时候该Block

不是所有问题都值得阻止合并

这可能是Code Review里最微妙的技能:判断什么问题必须现在解决,什么可以后续优化。

必须Block的:

✋ 会导致数据丢失的问题
✋ 有安全风险的代码
✋ 影响用户体验的性能问题
✋ 会造成内存泄漏的逻辑
✋ 有race condition的并发处理
✋ 未来难以修改的架构决策

可以放行的:

✅ 可读性改进
✅ 不常执行路径的小性能问题
✅ 非核心功能的边界测试
✅ 代码风格偏好

对比这两段代码:

// 这个必须Block - 会留下一堆脏数据
asyncfunction deleteUser(userId) {
await db.users.delete(userId);
// 等等,用户的帖子、评论、关系怎么办?
// 删不干净会导致数据一致性问题
}

// 这个可以放行 - 只是风格问题
function getUserDisplayName(user) {
return user.firstName + ' ' + user.lastName;
// 可以用模板字符串,但这样也能用
}

第一个会在生产环境造成数据混乱,第二个只是写法偏好。

判断标准很简单:这会导致生产事故吗?会让代码库显著难维护吗? 如果答案是否,建议改进但别阻止合并。

第六个沟通技巧:解释"为什么",而不只是"怎么做"

好的Review是在教育,而不只是审查

对比这两条Review评论:

弱评论: "这里应该用useMemo"

强评论: "这个计算每次渲染都会跑,处理1000+项目。用useMemo包裹,依赖项设为[items],可以避免其他状态变化时重复计算。我本地profiling显示渲染时间从80ms降到5ms。"

差异在哪?

第二条评论不只说了做什么,还解释了:

问题是什么: 每次渲染都重复计算
为什么重要: 处理大量数据,影响性能
怎么解决: 用useMemo缓存结果
效果如何: 实际性能提升数据

当你解释"为什么"时,你不是在给指令,而是在传授思维方式。 开发者学到的不是规则,而是原则。下次遇到类似场景,他们就能自己判断该怎么做。

这在反对某种方案时尤其重要:

❌ "这个方法不对"
✅ "这个方法在下个sprint加入多用户功能时会出问题,因为它假设只有一个活跃用户。我们需要重构成支持多用户的结构,现在改比上线后改容易得多。"

第二种方式提供了上下文,让开发者理解更大的图景。这样的反馈引导理解,而不只是强制服从。

第七个长远视角:为未来的维护者写代码

今天写的代码,明天就会变成别人的噩梦

代码的生命周期远比你想象的长。今天你花2小时写的功能,可能半年后需要改动。那时候:

你可能已经忘了细节
可能是新同事在改
可能是凌晨3点线上出bug你在查

高级开发者审查代码时,想的是:"这段代码能不能脱离作者独立存在?"

// 缺少上下文 - 半年后没人知道0.88是什么
function calculatePrice(item) {
  return item.basePrice * 0.88;
}

// 有清晰上下文 - 未来维护者能理解
function calculatePrice(item) {
  // 扣除12%平台手续费 (0.88 = 1 - 0.12)
  // 详见定价文档: https://docs.company.com/pricing
  return item.basePrice * 0.88;
}

魔法数字0.88让人一头雾水。注释解释了它的含义和出处,未来的开发者不用到处找文档或问人。

同样重要的是识别"技术上正确但让人困惑"的代码:

// 能跑,但看着累
const isValid = !!data && !!data.name && data.name.length > 0;

// 同样逻辑,意图清晰
const hasValidName = data?.name && data.name.length > 0;

第二种写法更容易理解。有人快速浏览代码时,不用解析布尔逻辑就能明白在检查什么。

可维护性不是奢侈品,而是必需品。 每次Review都是在为未来投资,减少技术债务,让代码库保持健康。

第八个判断力:知道什么时候该当面聊

有些问题靠评论解决不了

当一个PR方向根本就错了,你写再多评论也没用:

架构选择有根本问题
对需求理解有偏差
技术方案从起点就跑偏

这时候别写长篇大论的评论,直接拉个会聊。

"嘿,我觉得咱们应该聊一下这个PR。我对整体方案有些担忧,实时讨论会比来回留言快。"

当面讨论的好处:

作者避免走弯路浪费时间
审查者不用打字打到手抽筋
双方能快速达成共识
可以即时澄清误解

Code Review评论适合处理具体的、局部的修改建议。对于需要重新思考整体方案的情况,它就是错误的沟通方式。

知道什么时候切换沟通渠道,这是高级开发者的关键软技能。

第九个平衡术:信任与教导之间的微妙关系

Code Review最难的不是技术,是人

做Code Review最难的部分不是技术判断,而是社交平衡。

你需要:

信任作者经过了思考,有他们的理由
怀疑他们可能没看到某些坑
教导他们不知道的模式和风险
尊重他们的决策,即使和你的不同

这种平衡很难把握。太严格会打击积极性,太宽松会放过问题。

一个技巧是从好奇开始,而不是纠正:

❌ "你应该用方案Y而不是X"
✅ "我好奇为什么选择方案X而不是Y? 我之前遇到过Y在这种场景下更合适的情况"

第二种说法:

假设作者有理由(也许他们试过Y不行)
表达了你的经验,但不强加观点
开启了对话而不是命令
也给你机会学习(也许他们知道你不知道的事)

同时,该教的时候别藏着掖着。初级开发者不知道自己不知道什么。你发现的模式和坑,如果不解释清楚,他们下次还会犯。

这种社交技能——在信任、教导和共情之间找平衡——才是区分高级审查者和一般审查者的关键。

最后的底线:完美不是目标,出货才是

Code Review不是追求完美,而是在保证质量的前提下让代码尽快上线。

每条评论都有成本:

作者要花时间修改
功能上线被延迟
可能产生团队摩擦

所以问题不是"什么地方可以更好?"——因为代码永远可以更好。

真正的问题是:"什么必须在上线前改变?"

这个列表要短得多:

✋ 会造成生产事故的问题
✋ 会让代码库难以维护的决策
✋ 有明显安全隐患的实现

其他的:

✅ 作为下次的改进建议
✅ 写在文档里给未来参考
✅ 作为个人偏好就别提了

最好的Code Review是那些发现了微妙的race condition或架构问题,避免了几周的痛苦的Review。 不是那些纠结变量命名和格式的Review。

知道区别。审查真正重要的东西。

写在最后

如果你读到这里,我希望你能重新思考Code Review的目的。

它不是展示你知道多少规则的舞台,不是刷存在感的机会,更不是追求完美代码的工具。

Code Review的真正价值在于:在代码进入生产前,用经验和判断力筛选出真正重要的问题。

下次做Review时,问问自己:

这个问题会导致生产事故吗?
这个建议会显著提升代码质量吗?
这条评论值得占用团队的时间吗?

如果答案是否,就让它过。把精力留给真正重要的战斗。

因为注意力是有限的,leverage才是无限的。

罗永浩VS贾国龙：预制菜纷争背后的行业真相

Fri, 12 Sep 2025 13:51:26 +0800

罗永浩吐槽，贾国龙强硬回应

9月10日，一向口无遮拦的罗永浩发文吐槽西贝。他称下飞机和同事去吃西贝，发现几乎全是预制菜，价格还贵，感觉“实在是太恶心了”，甚至希望国家推动立法，强制饭馆注明是否用了预制菜。其实，这不是罗永浩首次对预制菜开炮，去年11月他就表达过餐厅卖预制菜不注明是欺骗的观点。

9月11日下午，西贝创始人贾国龙迅速回应，称西贝门店所有菜品都不是预制菜，还将起诉罗永浩，并且表明“不会对骂”，选择诉诸法律。

罗永浩则在微博回应网友，表示不怕，如果西贝靠文字游戏打赢官司，过程中真相也会泄露，公道自在人心。

贾国龙还详细解释预制菜标准，强调西贝菜品和预制菜不同，并透露9月12日起西贝全国370多家门店将开放后厨，公开“罗永浩菜单”。

对此，罗永浩晚间再次回应，质疑西贝能把现做菜做得像重新加热的味道是“高科技” 。

西贝预制菜探索之路

西贝餐饮集团历史悠久，1988年成立，从内蒙古的一家“黄土坡风味小吃店”，到1999年改名为“西贝莜面村”定位西北菜，如今全国近400家门店覆盖62个城市。不过，西贝因菜品价格较高常被消费者诟病。

事实上，西贝也曾涉足预制菜领域。2019年9月推出首款预制菜产品“贾国龙功夫菜羊蝎子” ，12月上线“贾国龙功夫菜”品牌，主打家庭消费场景。但西贝的预制菜之路并不顺遂，2022年媒体报道显示，其旗舰店销量最高的产品月均销量也仅100多份，多数功夫菜产品月销量未突破100份。

贾国龙也曾表示不想成为预制菜公司，而是想提高菜品标准化水平，2024年西贝功夫菜聚焦杂粮主食赛道。

今年3月，六部门联合发文推广餐饮环节预制菜明示，这对餐饮行业预制菜规范提出了新要求。

“现炒”与“预制”界限模糊

随着餐饮连锁化发展，预制菜在餐饮行业应用越发广泛。预制菜是以食用农产品及其制品为原料，经工业化预加工制成，加热或熟制后可食用的预包装菜肴。

此前，老乡鸡、绿茶餐厅等餐饮品牌也曾因预制菜问题引发争议。老乡鸡董事长束从轩曾公开回应称老乡鸡坚持现炒，央厨只是切配净菜，门店再现炒。然而，目前预制菜行业内对于其定义尚未形成统一标准。消费者认为不在门店现做的算预制菜，而餐饮商家则觉得只有中央厨房完全加工好、门店只需加热出餐的才是预制菜。

业内人士分析，界限模糊一方面是预制菜加工方式多样，另一方面部分商家为提升效率、降低成本采用预制工艺，宣传却强调“现做”，导致消费者认知偏差。

消费者对预制菜态度也有分歧，有人觉得方便快捷，有人则担心口感、新鲜度和食品安全问题。

餐饮行业专家指出，预制菜本身没错，是行业发展产物，但商家应尊重消费者知情权和选择权。

这场罗永浩与贾国龙的纷争，就像一面镜子，映照出预制菜行业在发展过程中的诸多问题。无论是商家的菜品定位，还是行业标准的缺失，亦或是消费者的态度，都需要在未来进一步探讨与规范。希望在未来，预制菜行业能在健康的轨道上发展，让消费者吃得明白、吃得放心。

苹果公司定价策略分析，为什么手机越来越贵而电脑越来越便宜？

Fri, 22 Aug 2025 13:56:26 +0800

有消息称，苹果预计将于2026或2027年发布折叠款高端iPhone（可能命名为iPhone Fold或iPhone Ultra），首发价15999元起。
有消息称，苹果将用iPhone 17Air来代替Plus系列。
有消息称，苹果准备砍去iPhone 18基础款型号。
有消息称，苹果正筹备超低价MacBook，预计起售价4300元。

是不是快看晕了，一年之内传出这么多新品动向，似乎不太像往常“稳健”的苹果。

那我们该如何理解这些频繁的动作呢？

手机：中间塌陷，两头增长

全球消费电子市场正在形成一个趋势：“两头强、中间弱”。

高端机有为追求身份与极致体验的高收入人群设计，比如折叠屏手机；而低端机因价格和实用性受到预算有限群体青睐。哪儿也不是的中端机就日益被边缘化，销量承压。

调研机构IDC预测，2025年中国智能手机市场中，600美元（约4300元）以上的高端机型份额将提升至30.9%，同比增长2.1%；而价格低于200美元（约1400元）的低端机型也增长至31.5%，同比提升2.1个百分点；但“200~400美元”的中端市场份额则可能下滑至28.0%，减少4.2个百分点。

说回到高端的折叠屏手机吧，最出名的莫过于三星和华为。

三星多年来快速迭代折叠屏手机，在高端创新上抢占了先机。

而苹果选择更谨慎的跟随策略：等待技术成熟后再推出自家折叠iPhone，以期一举超越现有产品体验（例如消除折痕的屏幕设计）。

在价格方面，三星最新的Galaxy Z Fold7起价约1999美元，而苹果折叠机型传闻定价也是在2000美元起跳——最昂贵的定价意味着苹果有信心以品牌和体验溢价，直接锁定超高端客群。

至于华为，三折叠的设计更像是“电子茅台”，并非为了大规模盈利。

在当前语境下，Mate XT更多是一种在美国制裁下展现科技实力的“象征性”产品。

于是，在手机层面就好理解了。

中间弱，两头强。对应到苹果的产品线，最尴尬的就是Plus。

我根据市场数据，统计了美国市场Q1口径的近几年iPhone各系列的销量占比。

注：Q1的iPhone数据比Q4更能反映市场的真实情况，因为Q4有“首发热潮”和“假日季”的干扰；而Q1销量仍然较高，但机型分布已经趋于稳定，所以更具代表性。数据之和不是100%的原因是有部分旧机型在销售。

数据说明，即使新发布的系列通常占总销量的70~80%，但Plus的表现始终不理想。

喜欢大屏的用户可能更倾向于买ProMax；想省钱的就直接买标准款或者旧款了，Plus夹在中间，两头都不讨好。

所以，也就能理解为什么苹果决定停掉iPhone 17Plus，用iPhone17 Air接替它了。

虽然定价依然在同一区间，但Air的定位是“极薄、轻巧”，与Plus“只是大屏和长续航”的思路不同。

AxisIntelligence称，分析师预计iPhone 17Air或将在17系列中占15~20%的份额，表现会优于Plus。

紧接着，让我们把目光放在iPhone 18上。

之前就有消息称苹果将推迟发布iPhone 18的基础款，后来又有新闻说，或将考虑直接移除基础款iPhone 18。

这并非没有逻辑。

苹果推出iPhone 16e，本来就是想取代原有的iPhone SE（第3代）作为苹果的低端入口机型，然而其定价（$599）相较于SE（$479）大幅上涨，又仅比标准版iPhone 16便宜$200。

行业舆论普遍认为iPhone SE销量表现不佳、市场需求有限，苹果推出iPhone 16e本质是想用更现代的设计、增强体验来替代SE，但这一策略在“低价”方面并没有带来优势，甚至可能削弱了部分用户的购买意愿。

SE的低价优势没了，16e也未能达到足够影响力（但优于SE）。

如果未来继续推出iPhone 18e，而同时保留基础款，两者在定价和定位上将重叠。与其互相内耗，不如直接砍掉基础款。

就算是iPhone 18e，苹果也要决定推迟发布，选择首先发布Pro和折叠机的机型。这种策略调整则更多被媒体解读为是营销节奏与利润最大化的策略。

即苹果试图先推动高溢价、高关注度机型（如Pro和折叠机），再在“冷场期”推出中低价款来刺激补充销量、维持曝光与市场兴趣。

这样做也可以降低对品牌高端形象的冲击。

电脑：低价的逻辑

电脑领域，苹果的定位不太相同。

传闻中的$599MacBook虽然定价远低于现有MacBook，但苹果将采用成本更低的方案以维持盈利：例如改用A18Pro芯片（与iPhone 16Pro相同），代替成本更高的M系列芯片。

这款MacBook预计也将阉割部分高成本配置（如采用Thunderbolt端口、仅8GB内存等），控制物料成本。

更何况A18Pro体积更小、架构更简单，因此生产成本较低。这意味着即便售价下探，苹果仍可通过自研芯片优势保证合理毛利。

所以，为什么苹果突然要出一款低价的MacBook？

关键背景在于：微软宣布Windows10将在2025年10月14日停止支持。

这意味着在那天之后，Windows10将不会再收到任何安全补丁、功能更新或漏洞修复。

如果系统一旦不再有安全补丁，新的漏洞将无法被修复，用户更容易受到病毒、木马或勒索软件攻击。

同时，新出的硬件、驱动和应用程序可能不再支持Windows10，只会面向Windows11或更新系统做优化。

最后，还有可能涉及到企业合规问题。一些行业要求必须使用有安全支持的操作系统，否则可能被视为不合规。

为什么说这是个重要的消息？

Windows10目前依然是全球使用量最大的桌面操作系统之一。根据StatCounter2025年的数据，Windows10仍占据大约60%的Windows市场份额。

停止更新意味着数亿台电脑需要升级或换机。

一般来说，电脑可以直接系统更新到新版本的Windows系统，但微软要求CPU至少是Intel第八代（2017年底之后），并且必须支持TPM2.0、安全启动等。

这意味着，需要更换电脑的群体也许有几类，但他们都有一个属性——必然不会经常更换电脑：

一，买的高端机型。电脑寿命长，性能过剩，所以不着急换。这类群体显然较少，不在苹果的考虑范畴。

二，买的低价机型。预算有限，不愿意频繁换机。这类用户普遍价格敏感，升级意愿低，正是传闻中苹果“低价MacBook”可能瞄准的市场。

三，企业用户。由于兼容性或IT管理政策，无法短时间内大规模升级，同时换代成本也高。

也就是说，如果在此发力，如果能够抓住这些需求，就可以即刻给苹果带来更多的营收。

分析师郭明錤（Ming-ChiKuo）预测，这款低价机可能贡献500~700万台出货，帮助MacBook出货总量重回2500万台/年的高峰。

2023年MacBook总出货量仅约1800万台，差距就是很明显。如果低价机成功，就相当于恢复了约30~40%的销量缺口。

中端Windows笔电、Chromebook也不是不存在。但至少对于学生党、轻办公用户来说，价格差距不再是阻碍，macOS的生态和iPhone的联动（AirDrop、iMessage、iCloud）将成为强吸引力。

苹果这些动作看似矛盾，一边推高iPhone的天花板，让折叠屏、ProMax继续冲击两万元的超高端市场；一边又下探MacBook的地板，用低定价去撬动原本属于Windows和Chromebook的市场。

但如果结合市场趋势来看，就会发现这是同一逻辑的两面。手机市场正在走向“沙漏型”——高端和低端增长，中端逐渐塌陷；而电脑市场则在Windows10停止支持的换机潮中出现了一个机会窗口，此时切入更有胜算。

于是，苹果在手机端于是就干脆砍掉“中不溜”的Plus与基础款，把资源集中到“极致体验”和“极致性价比”两端；在电脑端则主动突破价格底线，用一款低价机把价格敏感的学生、轻办公用户和一部分企业市场拉进自家生态。

腾讯音乐12.6亿美元现金“闪购”喜马拉雅

Fri, 13 Jun 2025 10:25:59 +0800

这两天，腾讯音乐吃了个“大蛋糕”——全资收购了喜马拉雅，瞬间成了音频界的“大爷”。作为一名普通听众和网易云音乐的付费用户，看到这场“声音界的合体升级”，不禁想来跟大家聊聊这盘“声音江湖”的新棋局。

先说说这桩大买卖：腾讯音乐花了大概12.6亿美元（折合人民币90多亿，再加一笔小小的股权置换），把喜马拉雅收入囊中。喜马拉雅的估值缩水一半多，从巅峰期的50亿美元跌到24亿美元，堪称在线音频界的“跳水冠军”。不过双方嘴上说着“品牌不变、管理不变”，但其实背后是腾讯想打造一个“一站式声音帝国”，从音乐跨向有声书、播客甚至知识付费，搞个“声音全家桶”。

咱们作为普通用户，看这场“声音联盟”最关心的事就是：以后听歌听书会不会更方便？会不会多花冤枉钱？别急，慢慢聊。

腾讯音乐这几年有点尴尬——用户增长像头顶的秃毛，停滞不前了，还得硬扛着老对手字节跳动的“汽水音乐”和“番茄畅听”的“流量洪水”。而喜马拉雅自己也日子不好过，IPO四次碰壁，营收增速掉到个位数，广告变少，裁员降本……这两者合体，正像两个被“拽”着的孤岛，强强联手试图征服声音大陆。

综合喜马拉雅历次招股书来看，依靠订阅/广告/直播等服务内容，从2018—2023年，营收分别为14.76亿元，26.98亿元、40.76亿元、58.57亿元、60.61亿元、61.63亿元；虽持续增长，但同比增速已从2018年的超过100%下降至2023年的1.68%。

这买卖对于行业来说，就像江湖里的两大派系要合并，势必改变江湖格局。腾讯系毫无疑问要成“声音霸主”：音乐、长音频一把抓，打造出“腾讯系版的声音长城”，对抗字节跳动系的免费打法和算法攻略。

对咱们普通用户来说，未来的会员可能会变成“超级会员包月”，音乐、有声书、播客一锅端，听起来很香。但别忘了，价格会不会跟着蹭蹭涨，那就得看腾讯的良心值多少钱了。

另外，合并后的技术玩意肯定不少——AI造声、智能推荐、声音定制都要上场，听书听歌体验估计会更“懂你”，不过也容易产生“听你听着听那啥”的推荐怪圈，毕竟算法有时候比小编自己还爱“云吸猫”。

当然，天下没有完全的“甜蜜”，这场合并也面临反垄断的监管雷霆，业务整合的文化冲突，喜马拉雅能不能维持独立味儿，还有那些靠声音谋生的内容创作者们，待遇会不会缩水……都是悬着的“梗”。

最后，作为网易云音乐的付费用户，真心希望网易云继续保持它的社区氛围和独特调调，不管大鱼如何吃小鱼，我们普通的听众都希望有多一家平台守住那份真诚和发现好音乐的乐趣。

总结一句话：这次腾讯音乐吃下喜马拉雅，既是一次“英雄联盟”，也是声音世界的“宿命轮回”。走好这步棋，能让我们听觉丰富起来；走不好，恐怕就成“专治听众选择困难症”的大帮手了。

不管怎样，戴上耳机，我们静待这场声音盛宴的下一章吧！

智能体开发平台大盘点：Coze、Dify、腾讯元器、文心智能体

Tue, 03 Jun 2025 10:39:42 +0800

— 1 —

Coze：简单好上手，社交平台的好帮手

Coze是字节跳动推出的智能体开发平台，定位于“让每个人都能轻松打造AI应用”。它的核心亮点是简单易用，特别适合想快速上手的个人用户和小团队。

优点：

超低门槛：拖拽式界面+现成模板，哪怕你是零代码小白，也能几分钟做出一个智能体。比如，想做一个“自动回复微信客服”的小助手？选个模板，改几句提示词就行！
跨平台分发：智能体可以一键发布到微信、抖音等社交平台，特别适合想在社交场景中用AI的创业者或营销团队。
国内大模型支持：国内版Coze支持Kimi、百川、智谱等大模型，生态适配性强，适合中国市场。

缺点：

功能深度有限：Coze更偏向简单任务的自动化，比如聊天机器人或基础客服。如果需要复杂的工作流（比如多数据源联动），可能会觉得不够灵活。
国内版模型受限：相比海外版，国内版Coze只能用国内大模型，模型选择范围较窄，可能影响某些特定场景的表现。

适用场景：

个人用户：想做个有趣的聊天机器人或社交媒体自动回复工具。
小微企业：需要快速部署客服或营销智能体，预算有限又想省心的团队。
案例：小李用Coze做了一个抖音私信自动回复机器人，帮他的小店每天自动回答上百条“包邮吗”的咨询，省时又省力！

Coze支持多种发布平台。

— 2 —

Dify：企业级AI开发的“瑞士军刀”

Dify 是一个开源的AI应用开发平台，背靠前腾讯云DevOps团队，专注企业级AI解决方案。它以低代码和灵活性著称，适合需要深度定制的场景。

优点：

强大的模型兼容性：支持数百种国内外大模型（包括GPT、Llama、Mistral等），还支持RAG（检索增强生成），能轻松整合企业知识库，生成精准回答。
低代码+开源：提供可视化工作流编辑器，非技术人员也能上手；开源社区版让开发者可以深度定制，适合有技术能力的团队。
企业级功能：支持LLMOps（大模型运维），能监控应用性能，适合需要长期维护的复杂项目。

缺点：

学习曲线稍陡：虽然有低代码界面，但复杂功能（如多数据源联动）需要一定的技术背景，初学者可能需要摸索。
收费偏高：云服务版按美元计费，对国内用户来说成本较高，中小企业可能觉得有点“肉痛”。

适用场景：

中大型企业：需要开发复杂的AI应用，比如客户服务机器人、数据分析助手或内部知识管理工具。
开发者团队：希望深度定制AI工作流，整合多种数据源（如PDF、数据库）。
案例：一家电商公司用Dify开发了一个智能客服，能自动从产品数据库提取信息，回答客户关于尺码、库存等复杂问题，效率提升30%！

— 3 —

腾讯元器：背靠微信生态，连接亿级用户

腾讯元器（Yuanqi）是腾讯基于自研混元大模型推出的智能体开发平台，深度整合微信、QQ等生态，适合需要社交场景赋能的用户。

优点：

微信生态加持：元器开发的智能体能无缝接入微信小程序、公众号，触达亿级用户，特别适合做C端产品或营销活动。
多模型策略：除了自研混元模型，还支持DeepSeek等开源模型，推理能力强，适合复杂任务。
企业级支持：提供API/SDK，方便集成到企业系统，适合需要规模化部署的场景。

缺点：

生态依赖：元器的最大优势在腾讯生态内，离开微信/QQ后，功能吸引力会打折扣。
起步较晚：相比Coze和Dify，元器推出时间较晚，社区生态和模板资源还在完善中。

适用场景：

社交电商/营销：想在微信生态内做智能客服、营销助手或互动游戏的商家。
企业用户：需要将AI能力嵌入微信小程序或企业系统的公司。
案例：一家餐饮连锁用元器开发了一个微信小程序智能点餐助手，用户语音点单后，助手能自动推荐套餐，订单量提升了20%！

腾讯元器只支持腾讯生态的平台。

— 4 —

文心智能体：百度流量加持，商用化利器

文心智能体（AgentBuilder）是百度基于文心大模型推出的平台，分为C端（个人用户）和B端（企业用户）的千帆AppBuilder，专注快速构建商用化智能体。

优点：

流量支持：背靠百度生态，智能体能通过百度搜索、灵境矩阵等渠道快速触达用户，适合需要流量的开发者。
低门槛开发：支持零代码/低代码开发，普通用户也能快速上手；提供丰富的行业模板，比如教育、电商等。
商用化能力强：千帆AppBuilder专注B端，提供专业化工具，适合企业快速构建AI应用。

缺点：

功能细分复杂：C端和B端平台分开，初学者可能需要时间搞清楚两者的区别。
社区生态较弱：相比Dify的开源社区，文心智能体的社区活跃度稍低，资源共享较少。

适用场景：

个人开发者：想快速开发C端智能体，借助百度流量推广。
企业用户：需要为特定行业（比如教育、医疗）定制AI应用的团队。
案例：一位教育博主用文心智能体开发了一个学习助手，能根据用户输入生成个性化学习计划，发布到百度平台后，吸引了大量学生用户。

百度的文心智能体平台仅支持微信的发布平台。

— 5 —

怎么选？

看你的需求！

想快速上手，玩转社交平台？ Coze是首选，简单易用，分发方便，适合个人和小团队。
需要企业级AI，深度定制？ Dify是你的“瑞士军刀”，支持复杂工作流和多模型整合。
深耕微信生态，触达亿级用户？ 腾讯元器背靠微信，适合社交电商和C端产品。
追求流量和商用化？ 文心智能体有百度生态加持，C端B端都能玩转。

使用Dify实现Text2Sql功能并输出图表

Tue, 22 Apr 2025 11:13:07 +0800

最近业务需要，研究的dify插件比较多，今天看下两个基础插件：database 和 echarts ，以及看下如何将其应用到对话过程中；

基础概念

Text2sql ：是个“翻译官”，你只需要对着电脑大喊：“给我找上个月花500以上的VIP螺蛳粉爱好者！” ，AI自动把这句人话转成SQL代码，数据库秒懂，直接吐结果。本质就是个“人话 → 数据库黑话”的转换器。说白了就是让数据库听懂人话的魔法

ECharts：让数据“骚”起来的可视化工具，把枯燥的数字变成炫酷图表的“数据化妆师”，专治“Excel 图表太丑”和“PPT 毫无亮点”两大职场绝症。ECharts = 数据界的特效大师，让图表从“路人甲”变成“奥斯卡最佳视觉效果”！

Dify 是啥？

想象一下，你有个超强但“傲娇”的AI助手，你想让它：当客服（但别乱说话）、查公司文档（别瞎编）、自动写周报（别写成科幻小说）；正常情况，你得：学编程（写API）、调Prompt（防AI“胡言乱语”）搭服务器，搞运维（然后头发掉光）但有了 Dify，你只需要：拖拖拽拽（像玩《我的世界》搭房子）、选个模板（比如“AI客服”“文档问答”）、点发布（搞定！）本质：一个“AI应用组装车间”，把大模型、你的数据、业务逻辑像乐高一样拼起来，还能随时调整。

这三个结合起来会有什么不一样的效果？

先看下结果：

在聊天界面，我们不仅看到了数据，而且还以图表的方式展现了出来；更绝的是，这些数据原本只是数据库里面的记录，完全无需的原始记录，在 dify+database+echarts 的合力下，变成了看得见，摸不着的画面了；

怎么实现的？

第一步：源码安装dify，我之前文章有详细介绍，可以参考下；

第二步：在插件里面找 database插件

找到后，点击安装；插件就出现在我的插件列表里了；现在我们对他授权数据库访问：

点授权，输入授权格式，对于mysql数据库，用下面的方式：

mysql+pymysql://用户名:密码@地址:端口/数据库#注意，由于是容器内运行的插件，地址必须是容器可访问的地址，比如写 127.0.0.1 的话，就连不上了

这里有四项功能，不一一解释了，有用的我觉得就 Text to Sql 和 Sql Execute了

第三步，按中同样的方式，安装 echarts，也是搜索、安装即可；echarts不需要授权；

第四步，咱们来创建工作流了；

搞个简单的对话流程，这里面区分下，是要报表的，还是要结果数据的；不多讲，我们看看怎么把数据库数据弄出来的；

a. 先text2sql 一把，将用户对话变成sql：

b、再sql execute 一把，把sql 代码通过查库变成数据：

这一步的输入是 a里面的产生的sql，输出我们用markdown格式即可

c、对于只要数据的，我们输出即可，对于报表的，我们做点特殊处理：

先把markdown格式，变成标题、x轴、y轴的样子，就是加个参数提取器而已；

d、把数据通过echarts 转成报表，非常简单：

默认支持柱状图、饼图、折线图；更复杂的图也能实现，把数据结构定义好即可；不过这几个图大部分场景也足够了；

好了，以上逻辑就是dify中实现 text2sql 和报表展示功能，本来很早就想实现的，一直不敢进阶，这两天一下就搞明白了，看来技术不是太复杂；复杂的是人心。

前端开发又幸福了，Cursor + Figma MCP 快速还原设计稿

Tue, 22 Apr 2025 10:19:07 +0800

昨天朋友发给我一个开源项目 github.com/GLips/Figma…[1] 是一个 Figma 的 MCP 服务。

MCP 是最近比较火的概念，你可能在推特经常能看到。我用自己的话理解，简单讲就是一个开放给 AI 应用访问外部某某平台，某某应用的一个接口，AI 可以通过 MCP 来获取到更具体的相关数据。

站内优秀文章更详细的可以看下这篇文章的介绍 juejin.cn/post/747830…[2] (下图来源自互联网蛮形象的)

Cursor 不用介绍了吧。大名鼎鼎的 AI IDE Cursor 官网[3] 他支持绑定 MCP 服务，我使用的 0.45 版本，应该此版本以上都支持。在 Setting 中找到 MCP Server 进行添加配置。

我直接使用了下这个 Figma MCP + Cursor 感觉很不错，感恩开源。下面介绍下使用教程。

按照项目 Readme 操作

在 Figma 点击头像然后进入 Setting 先创建一个 Figma api-key。

给予一些权限。我这里给可读可写了。可自行修改。应该是至少需要 Dev resources 可读的。

复制下来生成的 api-key 然后在终端执行命令。

pnpx figma-developer-mcp --figma-api-key=<your-figma-api-key>

看到显示在本地 3333 端口启动服务了，就可以去 Cursor 链接了。

添加上亮小绿点就表示链接成功了。

2025.3.20补充内容最新版本 cursor 点击添加 MCP 是直接写入 json 文件了如下

{ "mcpServers": { "Figma": { "url": "http://localhost:3333/sse" } } }

在 Figma 复制选中的模块

指定要写入的文件，并提出相对应的要求。他就开始写了。（好像开启 agent 模式效果更佳，我直接使用的 nomal，朋友用 nomal 读取不到 Figma）

最后的成品下方是设计稿，上方是他一次性就实现的界面。还是很赞的，调整下高度和边距就可以用了。

import ReactECharts from 'echarts-for-react'; export default function LineChart() { const data = [ { date: '周一', value: 150 }, { date: '周二', value: 230 }, { date: '周三', value: 224 }, { date: '周四', value: 218 }, { date: '周五', value: 135 }, { date: '周六', value: 147 }, { date: '周日', value: 260 }, ]; const option = { tooltip: { trigger: 'axis', backgroundColor: 'rgba(255, 255, 255, 0.9)', borderWidth: 0, textStyle: { color: '#333', }, }, grid: { left: '1%', right: '1%', bottom: '1%', top: '3%', containLabel: true, }, xAxis: { type: 'category' as const, boundaryGap: false, data: data.map((item) => item.date), axisLine: { lineStyle: { color: '#E5E7EB', }, }, axisLabel: { color: '#6B7280', }, }, yAxis: { type: 'value' as const, axisLine: { show: false, }, axisTick: { show: false, }, splitLine: { lineStyle: { color: '#E5E7EB', type: 'dashed', }, }, axisLabel: { color: '#6B7280', }, }, series: [ { name: '客服消息量', type: 'line', smooth: true, data: data.map((item) => item.value), symbol: 'circle', symbolSize: 6, itemStyle: { color: '#1677FF', }, lineStyle: { width: 2, color: '#1677FF', }, areaStyle: { color: { type: 'linear', x: 0, y: 0, x2: 0, y2: 1, colorStops: [ { offset: 0, color: 'rgba(22, 119, 255, 0.2)', }, { offset: 1, color: 'rgba(22, 119, 255, 0)', }, ], }, }, }, ], }; return ( <ReactECharts option={option} style={{ height: '100%', width: '100%', display: 'flex', justifyContent: 'center' }} /> ); }

注意事项

如果使用的时候没成功的话请 check 以下事项

检查生成的 Figma api key 权限是否足够
检查 MCP 服务是否亮绿灯
复制设计稿 selection 的时候使用设计师模式
升级 npm 版本 github.com/getcursor/c…[4]
使用 agent 模式交流

结语

使用 Figma MCP 对比之前我直接截图给 AI 进行还原，进一步提升了准确性，原先 claude 是需要识别图片，现在可以直接读取 Figma 的元数据了。实现的效果更好了。感恩 AI，让我摸鱼时间更多了，逃~ 😂

参考资料

[1]

https://github.com/GLips/Figma-Context-MCP: https://link.juejin.cn/?target=https%3A%2F%2Fgithub.com%2FGLips%2FFigma-Context-MCP

[2]

https://juejin.cn/post/7478304240122134566: https://juejin.cn/post/7478304240122134566

[3]

https://www.cursor.com/: https://link.juejin.cn/?target=https%3A%2F%2Fwww.cursor.com%2F

[4]

https://github.com/getcursor/cursor/issues/2833: https://link.juejin.cn/?target=https%3A%2F%2Fgithub.com%2Fgetcursor%2Fcursor%2Fissues%2F2833

来源：量子前端