马年春节的脚步越来越近,大大小小的红灯笼挂满街头,屏幕里的集福活动再次点燃,家乡的腊味香气仿佛隔着千里也能闻到。无论是准备马年元素的春联窗花,还是添置一套杯盘碗碟新年新气象,又或是精心挑选一份产地直送的特色年礼,我们总愿用一些美好的物件,承载祝愿,点亮日常。今年,我们邀请了 9 位作者,分享他们为这个春节准备的「年货好物」。🙋 也欢迎大家在评论区,晒出你的春节心选!

本文不含任何推广性内容,请放心阅读,提前祝大家新春快乐!

好吃的

江中猴菇无糖酥性饼干 & 青稞米稀

@程天冲:每年到了春节回家,给家里人伴手礼都是一个不大不小的问题。我需要送礼的主要人群有两类:家里的老人,以及相熟的兄弟姐妹。显然,这两类人的收礼需求是完全不一样的,老人怕花钱又讲究实惠,兄弟姐妹们最好是能送出一点新意。所以看来看去,每年我都决定给大家送吃的,毕竟满足口欲对每个群体来说肯定都没错嘛。

与往年不同的是,我家老人们在今年因为一些疾病需要在较长一段时间内连续服用一些药物,并且日常服用的降压药和抗凝类药物也不能间断,又另外被医生要求日常控糖。我咨询了一下医生朋友发现,连续服用多种药物除了对有损肝脏以外,还会对胃有慢性潜在伤害,而这一点很容易被我们所忽视。所以在他的建议下,我决定今年给家里的老人送点好吃、养胃又健康的食品,江中自然就成为了我的首选。

春节都要吃零食,因此我选了这款猴菇无糖酥性饼干。首先从口感上,酥质的口感很容易被牙口不好的老人接受和喜爱,吃起来对牙齿完全没有负担;其次从控糖的角度,这款饼干直接的糖分物质添加为木糖醇,属于 0 蔗糖添加,并且还有三分甜版、不甜版两种供你选择,考虑到一块饼干本身的分量就很小,作为一个春节期间偶尔休闲的低 GI 零嘴来说很合适(当然了,配料表中依然包括小麦粉和全脂奶粉,如果有严格的碳水和脂肪控制需求可能需要注意);最后,作为养胃成分的猴头菇(添加量 >=6%)和山药的添加量也还不错,我认为完全可以达到养胃零食的需求。所以综合来看,作为送给老人的春节零食十分合适。

零食适合春节送礼,日常养胃才是关键。老人们都很认真吃早餐,包子油条挂面之类的精致碳水很容易摆上桌,所以我决定给他们换成青稞米稀。青稞作为一种非常优秀的低速升糖的粗粮,GI 值仅为 25 左右,甚至比燕麦的 55 还低不少 ,虽然作为粉状不经咀嚼会提高真实的升糖指数,但和常规米稀相比减少了炼乳,作为早餐控糖来说已经可以接受。

并且,这款米稀中还添加了 14% 的抗性糊精和 9% 的大豆分离蛋白粉,充分照顾到了膳食纤维和蛋白质的补充,对于早上需要日常服药的老人来说是一份合格的养胃控糖早餐。家里有和我情况类似的老人,可以考虑入手 30 装当个春季伴手礼试试看。

柠檬共和国柠檬芭乐电汽柠汽水

@程天冲:我家兄弟姐妹基本上已经全员进入三四时代,日常喝饮料的次数变低,而且也都更偏爱无糖茶类,家里东方树叶的常备数量已经堪比矿泉水。鉴于这种情况,送礼再送茶类就有点不礼貌了。过年不管怎么样都不可避免会吃得油腻一些,送些清新爽口的气泡饮料作为解腻饮料挺合适的。

这几年流行芭乐,大家夏天也都喜欢喝喜茶的芭乐茶,因此我就选了这款柠檬芭乐电汽柠汽水。这款饮料整体的添加物以原液果汁为主(不是无糖饮料,所以依然添加了白砂糖),包括番石榴(芭乐)、柠檬、苹果、茉莉花原汁及浓缩液,加上二氧化碳以后变成了非常清新爽口的气泡水。稍加冷藏之后,很适合作为春季餐桌的配饮,清新爽口且甜度不算很高,比单纯气泡水好喝,比单纯果汁口感更清透,春节送给自己的同辈或是好友都是挺好的选择。

澳门最香饼家粒粒杏仁饼

@许万里Alva:我第一次买它,是因为去年在拜访香港朋友时,她点名了这个牌子,说吃了几十年都觉得好吃。那次我顺手买了 10 盒回家分给亲戚和朋友,反馈都还挺好的:家里长辈喜欢它的炭香,觉得「配茶挺好」。朋友则更喜欢它的「粒粒口感」,觉得不是那种入口就散成粉的甜饼(虽然我觉得那种也好吃),吃起来更「实」。于是今年春节回家准备伴手礼时,我首先想到的还是最香饼家的手信。

它在澳门只有一家门店,位于本岛的夜呣街,从旅游观光地「议事亭前地广场」步行过去约 10 分钟。如果是节假日排队会很夸张,队伍甚至可以排到转角,店内也贴着「一人限取一票,一票限买一盒」。之前在官方介绍里看到它们旺季的日产量大概是 5000 块左右,人流多的话后面来的客人会买不到,所以才出了限购的策略。不过人不多的时候购买不会有数量限制,像我当时是工作日下午去买的,一次性买了 10 盒杏仁饼也是可以的。

这家店之所以有名,是因为它主打「古法炭烧手工制作」。官方介绍写得很详细:原料包括杏仁、绿豆粉、糖、植物油、花生酱等,先手工压模定型,再进炉烤到金黄。以前会更完全地用炭火慢慢烤,现在因为澳门法规限制,做法调整成「先烤半熟、再放上炭炉烤制」,仍然保留了独特的炭烤香气,很适合搭配热茶食用。

店里除了「粒粒杏仁饼」,还有肉心杏仁饼、蛋黄肉心杏仁饼(更偏咸香、油脂感更明显)等。此外他们也有做其他澳门手信,例如紫菜肉松凤凰卷、紫色卷、凤梨酥、榴莲饼、陈皮饼、鸡仔饼等等,都是比较有特色的港澳美食。如果是想送礼的话,可以搭配购买~

我常买的是 10 件装

元祖海盐太妃糖、桂花奶酥 & 大吃兄锅巴大王

@Voyager_1:不知道为什么突然赵一鸣、好想来等零食聚合的店铺突然火起来了,平时去超市买零食的习惯,被「去离家更近的零食店随便称点散装的」所取代。不过,这类零食还是以日常的零嘴为主,想吃老家也能随时买到,过年回家还是想着带些老少咸宜和平时不太会买的礼盒装带着,来亲戚朋友分食时既有新鲜感又觉得好吃。下面这几款就是这一年吃过的还不错的选项。

锅巴大王我买了两种口味,一种是甜辣另一种是蟹香。甜辣的就是日常能吃到的口味,更推荐下单蟹香口味,这款我妈这个不怎么吃零食的人吃了都说再来一个,锅巴上蟹粉裹得很够,吃完都得嗦下手指。这款独立包装,一袋一片非常适合过年等饭期间解馋。

过年怎么能不吃糖呢,小时家里茶几都会放一罐子糖,小朋友来家后习惯性就是抓糖吃,我决定把这个记忆延续下去。元祖的这款海盐太妃糖的甜度中和得很棒,比我随便在网上买的吃起来更加适口。(我不爱吃太甜的)嚼着吃、含化了吃,都能尝到果仁香,说明用料还不错。过年晒太阳的时候,泡杯咖啡配两颗糖,绝对惬意拉满。

过年想给奶奶买点桃酥来着,但是想着老人家都吃了一辈子桃酥了,该来点没吃过的试试。这款桂花奶酥应该适合她的口味,老人家不喜欢过冲的奶味/桂花味,这个我实际吃下来能吃到淡淡桂花香和馅儿料香,没有过冲的感觉,也没有咬合的压力。总体来说,元祖的出品还是让人放心的,希望奶奶会喜欢。对了,其实这种福饼也是可以切开分着吃的,长辈总是不爱一次吃一整个怕吃不惯浪费,分着吃就好了。

盒马年菜之金字刀板香咸肉

@文猫:前一阵在盒马上买了快手菜——笋尖咸肉煨豆腐,作为山西人没吃过这么好吃的咸肉汤,于是在很短时间内多次下单,成为在盒马最爱买的一款快手菜,但这款有点过于火爆了经常断货,于是在这种时候我只能买另一款——腌笃鲜。腌笃鲜比咸肉豆腐汤这款更方便,因为是铝盒包装,拿到手可以直接上煤气灶加热,连锅都不用洗了。

在我给老公激情推荐了咸肉豆腐汤但断货之后,他说那你为什么不买一下咸肉回来自己煮呢?于是我在盒马查了一下,有一款可以快递配送的咸肉,于是一下买了两袋。这个咸肉有塑封包装,一袋里面两条肉,开封后放冰箱冷藏就行,放两个月不成问题。盒马的老豆腐也不错,但不如咸肉豆腐汤(快手菜版)里面的柴火豆腐香,我在市集买的柴火豆腐也差点意思。

有了咸肉之后就非常简单了,我跟老公两个人的话一顿饭 用 1/3 条的咸肉量,切成片,厚度可以看自己喜好,更薄的话就会把咸肉的盐味更多煮到汤里,厚一点的话肉本身能留一些咸味。把切好的咸肉和切好块的豆腐放入锅中,大火滚几分钟可以让豆腐煮得烂一点汤更白一点,然后小火炖几分钟就可以。基础版只放咸肉和豆腐就很好吃了,有肉香和豆腐的豆香,我一个人话就会在汤里煮一份龙口粉丝,太好吃了!

如果想要口感更丰富可以加泡发的木耳和笋尖,能给汤增加一些鲜甜。出锅前撒上青蒜是跟盒马的快手菜学到的,但自己切的更香,因为更新鲜。

除了这道汤,盒马还出了很多与一饭封神合作的年菜,上次买了一个烧椒鲈鱼还是很不错的。但这些都是冷冻的,需要先解冻再蒸一下或微波炉加热,比较麻烦。

好看的

马年春联窗花静电贴

@Irisleilei:每年过年的仪式感已经固定为贴窗花了,可爱的窗花贴在室内赏心悦目,小玩意大作用,过节氛围感满满。相比贴在门外的对联的优势是在家里可以时刻感受春节的气氛,好看的东西就应该由自己和家人欣赏。

给自家安排的窗花贴

才把去年的蛇年窗花撕下来,静电窗花贴在朝南阳台经过近乎一年太阳的炙烤也几乎没有变色,也没有因此留胶,亲测完全无痕,轻轻一撕就下来了。由此,静音窗花贴已经成为每年固定仪式感。

今年没有固定在一家店买,挑了不同的店铺组合成好看的窗花,同时还有 DIY 的乐趣。(有些店铺原创的「马」不太像马哈哈,个人喜好还是选了有马的特征的)上下联和横批保持风格一致,中间的图案选了另一家店,福气满满和 ALL PASS 的寓意也算是符合自己今年的心境,希望自己少些对未来的焦虑,专注做事,幸运常在。

今年贴得更上手了,静音窗花贴的好处还有一个是,无限次重复贴,一个人贴也很方便。我通常会轻轻粘一个角固定位置,再在站远看看贴是否对称、水平,确认了再固定贴好,方便又快捷。

还给爸妈家也准备了一份,新的一年家里都要有新气象嘛。妈妈选了全是捧着金元宝和被金币簇拥的小马造型,全是对今年股市账户美好的祝愿(哈哈)。

马年创意春联

@Irisleilei:现在创意春联越来越多了,内容也越来越符合年轻人的口味,接地气儿又可爱。今年就早早地挑好了可爱的春联,谐音梗加分,希望 horse(好事)窍敲门!同时,除了入户门可以贴春联以外,也可以作为冰箱贴作为装饰。

我还是秉持着好看的东西要留在家里给自己欣赏,好看的春联忍不住多买几张,既可以作为冰箱贴吸在冰箱上也可以用无痕贴安置在房间门上,节日气氛爆棚。

奶油小狗春联

@Lotta:今年又刷到可爱的春联了!比起去年买的 Pingu 春联可爱程度更上了一个台阶,但价格也加了一倍。相比 50 多元 19 张的 Pingu 礼盒,这套春联 7 张定价就要 49 元。不过这套春联采用的是毛毡材质,似乎耐久度更高一些,作为独立小店的原创设计,价格也没多难接受(毕竟太可爱了)。

商家产品图

这套春联的主题是奶油小狗,深灰色的高脚托盘上是一摞红彤彤的草莓和一个可露丽,顶端各站着一只可爱的奶油小狗,写着「喵喵旺旺伴左右/日子甜蜜似奶油」的字样。虽然设计在春联这个品类有够特别,但缺点也很明显:作为对联来说既不对仗、也谈不上平仄相合,对此有要求的朋友慎选。

春联的包装很简单,一套七张被卷在一起装进透明袋子里,附赠了无痕贴和 3M 胶磁贴。春联印刷质量也很不错,几乎没有色差。虽然店家表明机器裁切可能会有白边,但不仔细看的话基本不会发现瑕疵。

这么可爱实在不舍得贴在大门外,于是我把它们贴在了室内的房间门上。虽然商家的示意图是七张都贴在了一起,但分组 DIY 也完全没问题,比如我觉得都贴在一扇门上有点拥挤,就把它们分成两组贴在了两扇门上,雨露均沾(bushi

我一开始也担心过草莓奶油的元素和春节的气氛并不匹配,虽然和马年无关,但贴上后却发现亮眼的红色确实也有喜庆的感觉,房间一下就活泼起来了!

新年仪式感冰箱贴

@Kasper:年关将至,极简北欧风的家也得疯狂注入红色元素,来点年味。但毕竟是节日限定,还得考虑到未来的拆卸,所以各类粘贴的东西都达咩,哪怕说的再天花乱坠如何不留痕,也不能给自己增加一丝麻烦。说起方便「穿脱」,最合适的就是磁吸材质了。家里的冰箱、咖啡机、垃圾桶、珐琅板……只要你想,哪里都是舞台!

马年真是一个各种谐音梗泛滥的年份,所以各种可可爱爱的马年整活小玩意真是让人买到手软。贴在大门上的对联当然还是要严肃认真,那就让磁吸对联来补足俏皮吧!我们家的冰箱贴一向是贴在冰箱侧面,主要是为了展示,以及避免开关门误触使其掉落,但既然是节日限定,那这个对联冰箱贴真是很适合独占一整面「大白墙」了。

不过,冰箱上的这个马年对联喜庆有余,谐音尚欠火候,于是我又购入了一个中英双谐音版冰箱贴,贴在客厅饮料冰箱和咖啡机侧面(horse 花生、马尼 go my home;超级马力、马足干劲;神马都顺、神马都好、马力十足)。

美中不足的是,这个系列的对联忽略了中国人春联的传统规则,加入了其他颜色,在一些地方习俗里可能不太吉利,所以只能挑选一些纯红色版本组合啦。

除了谐音梗,我还买了一个马年旋转冰箱贴系列,取「马上」之意,马背上驮着金元宝或福袋,意为「马上有钱」或「马上有福」,吉祥不失可爱。这个带点小机关的冰箱贴我贴在了铁皮置物柜和垃圾桶上,时时可以旋转一下。

以上冰箱贴都购于 pdd,价格较低廉,质量很难称得上完美,但很适合「沾点儿喜气」,用后即扔。你还真别说,平日里素色的黑白灰看惯了,点缀点色彩还真别有一番风味,已经开始期待过年了。

马踏繁花走马观烛台

@许万里Alva:今年因为我姐的推荐而开始对「香薰蜡烛」感兴趣,陆续买了两三个香薰蜡烛 & 烛台,最满意的还是和马年相关的这款 iasonas 的「马踏繁花走马观」,组装完成点燃蜡烛后的效果是令我感到惊艳的程度。它本质上就是中国传统的「走马灯」——利用热对流原理推动轮轴旋转,营造出马奔跑的动态画面。

因为走马灯转动如飞,在古代也有「转运」「走马上任」的美好寓意,通常伴有祈福的寓意,既适合用来送礼,也适合和我一样自购放在家里作为春节氛围感装置。它有两种观看方式,一种是直接观看;另一种是放入半透明透光片,让旋转的影子投在透光片上。我更喜欢第二种方式,在夜晚关闭家里的所有灯光,看着马的影子被拉长、变形,像小型皮影戏一样,很适合在夜晚小酌的时候观赏。

点燃走马观的效果

我是于淘宝购入这套走马灯礼盒,价格是 266 元,包含 8 枚香薰小茶蜡和 5 个透光片(虽然有 6 个方向,但官方建议是只放 3 片利于通风),到手后需要自己组装成品(不算复杂,我用了约 25 分钟完成)。它的香薰茶蜡有四种香型:木质调、西普调、柑橘调和草本木质调,在商品介绍可以看到每种香型的具体成分,每一枚蜡烛燃烧时可散发香味的时长大概为 4 小时。

商品礼盒包装

整体来说,这套香薰蜡烛 & 烛台我还是非常满意的,它不止香,而且转动的装置设计也让夜晚的家里更有氛围感,很适合过年放在家里添加一些趣味,也很适合作为礼物送人(今晚我姐看到的时候就马上找我拿了链接)~

生肖马克杯 & 袜子套装

@潘誉晗:母亲属马,公历的生日刚好在月底。因而今年购买年货的时候,与其说是为了祝福新年快乐,倒不如说是为母亲准备一份新年的生日礼物。

我们这代人的长辈,大多数的童年经历都是没那么富裕的,加上母亲又是从小地方考上大学的,所以性子比较务实,因而给她购买礼物,「实用性」必然是最佳的考量。前段时间发现母亲拿着并不是她常用的杯子喝水,我开玩笑说每天换着新杯子喝水是不是也很棒,结果母亲说,用另外的杯子只是为了方便吃药而已。想起吃药终究不是好心情,我们家的常用水杯就是按照生肖买的,所以开始在网上搜索有没有适合的生肖马克杯。于是发现了「故宫淘宝店」,就这么华丽丽地上新了一批马年新品。

马克杯、袜子、毛巾、毯子、对联、福字贴、上上签……各种类型的商品让人目不暇接,以「马」作为元素,中国红为主题颜色,看着就很是喜庆的模样。考虑到实用性,我最后选择了马克杯和袜子。

280 毫升的马克杯上的白色小马驹是浮雕的模样,真金纸花和红釉点缀其间,胖乎乎的杯子配合着圆圆的小马,很可爱,拿在手里也很有份量。设计的灵感来自于郎世宁的《万吉驦》,寓意是希望新年可以奋进不息,福运绵长。

商家产品图(左)/ 背面实拍图(右)

这家店的新年袜子有两款,一款走可爱类型,一款更成熟一点,我选择了更为符合母亲年龄的「马踏芳菲」系列。三双袜子的灵感来源于明嘉靖年间的「五彩天马纹盖罐」,寓意是愿福运随着步履绽放,新年可以一路生花、步步高升。收到这款我妈是真的很开心,穿在脚上说觉得整个人都喜庆洋洋的。

商家产品图(左)/ 实拍图(右)

好用的

MUJI 不锈钢厨师刀

@Vanilla:如果你之前在少数派上看到过我分享的《「长期主义者」的轻量化选择:这是我的 2025 年度好物推荐》,可能对我提到的「美的洗碗机」有印象。这么多月用下来,这个洗碗机已经成为了我们家使用频率最高的厨房电器,每天都在感慨相见恨晚。美中不足的是,我们家原来的一些刀具进了洗碗机后出现了涂层脱落的情况,同时一些锅因为手柄的原因也很难塞进这个尺寸的洗碗机中。

春节期间,自然少不了和家人、朋友们一起大快朵颐、聊天胡侃。于是,我和桃总决定在春节即将来临之际对厨房的部分物品进行一个升级替换,让我们在家里下厨没有后顾之忧。

俗话说「工欲善其事必先利其器」,一把好的厨师刀可以大大提高备菜的效率。于是,我们趁着这次机会,替换了所有脱层脱落的刀具。原来我们已经有一把使用多年的贝印旬刀和一把十八子作的桑刀,所以在替换选购的时候选择了两把尺寸更小的刀具来补齐空缺,更适合用来切水果和蔬菜的场景。同时,为了让用完的刀具都可以直接进洗碗机清洗,我们最终选择了一大一小的 MUJI 不锈钢刀具,不用担心涂层脱落或者木柄发霉,而且设计也很简单美观。同样,我们在选购厨房剪刀的时候也采用了同样的思路,全不锈钢的材质可以无忧地放进洗碗机清洗。

宜家磁吸刀架

@Vanilla:原来我们把所有的刀具都收纳在水槽边上,但是这种常年阴湿的环境很容易出现滋养细菌的情况。于是,我们决定给这些刀具换个收纳的地方,可以保证通风干燥,最好还能减少占用宝贵的台面空间。我立刻就想到了宜家这款经典的磁吸刀架,但是去宜家天猫旗舰店搜了一下发现已经下架了,只能通过第三方代购来购买。

这款磁吸刀架支持钉子和胶水两种安装方式,因为我不想破坏完整的瓷砖,所以选择了用胶水来固定刀架。一开始我买了 3M 的万能胶水,但是发现强度不够,完全支撑不住这么多刀具。后来我又紧急购买了德力西的一款胶水,这次终于将磁吸刀架成功固定在了瓷砖上,而且吸上四把刀加上一把剪刀也还是非常稳定。这种收纳刀具的方式,既可以保证刀具的通风干燥,又让取用变得特别方便,可谓一举两得。

Tefal 可拆卸系列锅具

@Vanilla:对于我们这样的两口之家,美的洗碗机 UP2Pro 用来洗洗碗筷绰绰有余,不过要是用来洗锅的话就有点勉强了。因此,我们在选择锅具的时候不再一味地求大,而是根据我和桃总的实际需求来选择合适的尺寸。桃总在经过一番比较后,选择了 Tefal 的可拆卸系列。我们在将这些锅具放进洗碗机清洗的时候,都可以将手柄卸下,节省了大量的空间,正好能将多个锅具一起塞进洗碗机。

另外,这个系列的锅具都可以使用同一个手柄,快拆设计让更换也非常简单。Tefal 锅具本身的素质也不错,法国制造的工艺看起来还挺精致,锅底受热均匀且不易粘锅,在日常的使用中非常得心应手,已经完全取代了之前被淘汰下来的「老伙计们」。

在经过一番简单的升级改造后,每次我们下厨的时候都比之前更加愉悦。一方面,备菜比原来更有效率,缩短了准备时间;另一方面,吃完饭只需要把碗里和锅里的食物残渣稍作处理,然后一股脑儿全部都放进洗碗机里等待清洗和烘干即可。不得不再次感慨一下中国家电行业的强大,1400 元出头就能买到功能强大、设计优秀还支持智能互联的洗碗机,让「今天谁洗碗」这个老大难问题从此终结。

关联阅读:

🙋:你有为春节采购吗?有什么好吃、好玩、好用的东西,欢迎在评论区一起分享。

题图来自 Unsplash

> 关注 少数派公众号,解锁全新阅读体验 📰

> 实用、好用的 正版软件,少数派为你呈现 🚀

    事情真的是从一件很小的事开始的。

    那天已经挺晚了,我在对一个功能做最后确认,本来只是想验证一条 Twitter 链接在未登录状态下到底会展示成什么样。

    没打算深究,更没想到会折腾这么久。

    我开了无痕窗口,把链接贴进去,加载了一下。
    第一眼看过去,好像也没什么问题。

    但当我刷新第二次、第三次的时候,就开始不太对劲了。

    同一个链接,每次打开都不一样

    有一次是完整内容。
    有一次时间线顺序变了。
    还有一次,直接跳到了登录页。

    当时我第一反应不是「Twitter 又搞限制了」,
    而是一个很工程师的想法:

    这要是线上功能,用户肯定会骂人。

    问题在于,它不是稳定复现的

    你没法拍着胸脯说:
    「未登录用户看到的就是这样。」

    因为你自己都看不明白。

    后来我才意识到,问题不在接口

    一开始我顺着老思路排查:

    • Network 里接口有没有 401
    • 返回数据是不是缺字段
    • 是不是被 rate limit 了

    结果发现,都不是。

    真正麻烦的是一件更抽象的事:
    你现在到底算不算“一个确定的状态”?

    未登录,并不等于简单的「没 token」。

    它更像是一个模糊态:

    • 有时被当作游客
    • 有时被当作潜在用户
    • 有时被当作需要引导登录的对象

    而不同状态下,平台给你的内容策略完全不一样。

    工程里最难处理的,往往就是这种“模糊态”

    这类问题有个共同点:

    • 没有文档
    • 没有报错
    • 没有明显异常

    但就是不稳定。

    你只能靠对照、靠猜、靠反复验证。

    后来我干脆换了个方式,不再只盯着自己的实现,
    而是去看别人是怎么“接受这种不完美状态”的

    我开始把 viewer 工具当成“参照物”

    这里我不是在找现成方案,而是找一种合理边界

    我会做几件事:

    • 同一个推文
    • 不登录
    • 多次访问
    • 对比展示结构

    过程中顺手看了一些 twitter viewer 页面。

    有些一看就很“猛”,
    明显在努力模拟登录态。

    也有一些(比如像
    Twitter Viewer 这种),
    反而显得克制很多——
    它基本接受了未登录能看到什么,就展示什么。

    当时我心里其实是松了一口气的。

    那一刻我意识到:目标一开始就定错了

    我最初的目标是:

    尽量还原登录用户看到的内容。

    现在回头看,这本身就是个高风险目标。

    因为这意味着:

    • 更复杂的逻辑
    • 更高的维护成本
    • 更容易踩平台规则的线

    反而,如果你一开始就承认:

    这是一个 public view,只服务公开信息

    很多设计决策会自然得多。

    顺便记录几个真实踩过的坑

    这些都不是教程级别的经验,更像是备忘。

    接口返回 ≠ 最终展示

    有些字段是给前端二次计算用的,
    直接展示出来反而不对。

    空值比缺失更容易出问题

    字段在、值是空,
    比字段不存在更容易让人忽略。

    viewer 场景下,缓存是刚需

    不是为了性能,是为了稳定预期

    现在我怎么看这些 viewer 工具

    说实话,我并没有把它们当成“要集成的功能”。

    更多时候,它们的作用是:

    当我不确定现在看到的东西合不合理时,
    给我一个外部视角。

    你可以把它理解成一个
    “未登录世界的观测窗口”

    这在调试阶段,比我想象中有用得多。

    写在最后

    这次经历让我再次确认一件事:

    很多问题,并不是“技术上做不到”,
    而是一开始站错了视角

    当你真的站在一个
    没有登录、没有权限、没有历史行为的用户位置上,
    你会发现:

    有些“不完整”,本身就是事实。

    工程要做的,不一定是对抗它,
    而是把它处理得足够清楚、足够诚实

    楼主自住的楼房,开盘时就考虑要不要买个仓储,当时是 1w 左右一平?得房率大概 57%左右,当时没买(幸好没买)。

    如今物业表示仓储打折了,仅需 4500 一平,看中了一套使用面积 10 平的大概 9w 多能买下来。

    楼主心动的原因:

    1. 位置好,在去车位的必经之路上,完全不用绕路
    2. 确实有使用需求,要考虑生娃了,需要把书房腾出来当成卧室,到时候要考虑给月嫂或者客人住
    3. 仓储房型板正;也没有返潮、异味的问题;有电,甚至可以拉网线,我可以把一些个人的主机、服务器、工作台、户外装备什么的放过去,然后也可以买自己想买的 3D 打印机了;家里的闲置杂物都扔到地下室,平时住起来更舒心

    楼主顾虑的原因:

    1. 我不确定这套房可以住一辈子或几十年,但是 10 年大概率还是有的。以后出手担心仓储成为负担
    2. 10w 块对我和老婆不会增加太大压力,但是现在这个经济环境下,我也要担心失业问题,10w 还房贷肯定更好。
    3. 10w 块也足够我扔几十年的闲置用品了。(但是目前书房那些东西,肯定舍不得全扔掉,然后会把大部分东西安排在家里的其它角落,我俩都是比较懒的人,只会显得家里更挤更乱)

    其它背景:

    1. 房子是新房,当年开盘均价 6w (是的,买在房价大跌的前一夜囧。。),位置在北京的某热门地块(可能也没有多热门,都是我自己看到的假象。。)
    2. 在物业群里问了邻居,出来发言的都表示不会买。开盘时有高价买仓储的,虽不多但是确实有几位不差钱的主。管家私下也跟我说近期打折也有透露购买意向的(当然可信度存疑)

    v2 社区卧虎藏龙,请各位帮忙从经济、实用型、情绪提升多角度谈谈你们个人的想法,如果换成你会不会买呢?

    很多新手在完成域名注册后,都会陷入同一个困惑:域名已经注册成功,为什么还是无法访问网站?其实答案很简单——域名注册只是第一步,后续的域名解析配置才是打通“域名与服务器”的关键,只有完成正确的解析配置,用户才能通过输入域名,顺利访问到对应的网站或服务。今天,国科云就为大家带来超详细的域名注册后解析配置方法,从准备工作到实操步骤,再到常见问题排查,全程干货,彻底搞定域名解析的所有难题。

    一、先弄清域名和IP之间的映射关系

    首先我们要明确一个核心认知:域名本身只是一个便于记忆的字符组合,而服务器才是存储网站数据、提供访问服务的核心载体。域名解析的本质,就是将人类易懂的域名(如www.xxx.com),转换为计算机可识别的IP地址(如192.168.1.1),让DNS服务器(域名系统)能够精准指引用户的访问请求,找到对应的服务器地址。简单来说,域名注册是“拿到门牌号”,而域名解析配置就是“给门牌号标注具体地址”,两者缺一不可,只有完成解析配置,域名才能真正发挥作用。对于新手而言,无需掌握复杂的技术原理,只需按照步骤一步步操作,就能完成域名注册后解析配置,轻松实现域名与服务器的联动。

    二、域名解析配置前,必做的3项准备工作

    在开始域名注册后解析配置之前,我们需要提前准备好相关材料和环境,避免操作过程中出现卡顿,确保解析配置能够顺利完成。

    1. 确认域名状态正常:首先登录域名注册平台,查看域名的状态是否为“正常”。通过WHOIS工具也可查询域名状态,若域名处于“ClientHold”“ServerHold”等异常锁定状态,必须先联系域名注册商解除锁定,否则无法进行任何解析配置操作。同时,要确认域名已完成实名认证(国内域名强制要求),未实名认证的域名会被限制解析,导致配置无效。
    2. 获取服务器公网IP地址:域名解析的核心是“指向服务器”,因此需要提前获取服务器的公网IP地址(IPv4格式,如192.0.2.0)。注意,要确保获取的IP地址正确无误,一旦IP输入错误,会导致解析失败,无法访问网站。
    3. 确认服务器与备案状态:若网站服务器位于中国内地,域名必须已完成ICP备案,未备案的域名解析至内地服务器,会被阻断访问,无法正常生效。同时,要检查服务器是否正常运行,通过IP地址直接访问,确认服务器能够正常响应,避免因服务器故障导致解析配置后无法访问。

    三、域名注册后解析配置方法(通用实操步骤,适用于所有平台)

    目前,市面上绝大多数域名注册商(如国科云、阿里云、腾讯云、西部数码)的解析操作流程基本一致,核心都是添加解析记录,完成域名与IP的关联。

    以下是域名注册后解析配置的通用步骤,无论你使用哪个平台,都能直接参考操作,全程无需专业技术,新手也能快速完成。

    步骤1:登录域名解析控制台。

    打开域名注册商的官方网站,登录自己的账号,找到“域名管理”板块,在域名列表中找到已注册成功、需要解析的域名,点击域名后方的“解析”按钮,进入域名解析配置页面。不同平台的按钮名称可能略有差异,有的显示“解析设置”“DNS解析”,但功能一致,找到对应入口即可。

    步骤2:确认DNS服务器地址。

    进入解析配置页面后,首先要确认域名的DNS服务器地址是否正确。域名注册商通常会提供默认的DNS服务器,若未修改过DNS,可直接使用默认服务器;若需要使用第三方DNS(如国科云解析DNS、阿里云DNS、Cloudflare DNS),需先在域名管理中修改DNS服务器地址,修改完成后需等待1-24小时生效,生效后再进行后续解析配置操作。建议新手优先使用域名注册商默认的DNS服务器,操作更便捷,解析稳定性也更有保障。

    步骤3:添加核心解析记录(重点操作)。

    解析记录是域名解析配置的核心,常用的解析记录类型有A记录、CNAME记录、MX记录,不同记录对应不同的使用场景,新手可根据自己的需求选择添加,其中A记录和CNAME记录是最常用的两种,用于实现网站访问。

    (1)添加A记录

    A记录的作用是将域名直接指向服务器的公网IP地址,适用于大部分网站搭建场景,也是新手最常使用的解析记录类型。

    操作方法:

    -点击解析页面中的“添加记录”按钮,选择记录类型为“A”;

    -主机记录填写“@”或“www”,“@”代表主域名(如xxx.com),“www”代表带www前缀的域名(如www.xxx.com),建议两者都添加,确保用户无论输入哪种域名都能访问;

    -记录值填写提前获取的服务器公网IP地址;

    • TTL(缓存时间)建议设置为10-60分钟,TTL值越小,解析生效速度越快,新手可直接默认设置;

    -填写完成后,点击“保存”,A记录添加完成。

    (2)添加CNAME记录

    CNAME记录的作用是将域名指向另一个域名(如服务器的别名域名),适用于服务器IP地址经常变化、使用CDN加速或虚拟主机的场景。

    操作方法:

    -点击“添加记录”,选择记录类型为“CNAME”;

    -主机记录同样填写“@”或“www”;

    -记录值填写目标域名(如xxx.cloud.com,由服务器服务商提供);

    -TTL设置与A记录一致,保存后即可完成CNAME记录添加。

    注意:同一主机记录不能同时添加A记录和CNAME记录,否则会导致解析冲突,无法生效。

    (3)添加MX记录(可选)

    MX记录主要用于配置企业邮箱,若需要使用自定义域名的邮箱(如xxx@xxx.com),则需要添加MX记录。

    操作方法:

    -选择记录类型为“MX”;

    -主机记录填写“@”;

    -记录值填写邮箱服务商提供的MX服务器地址;

    -设置优先级(数值越小,优先级越高),通常填写10、20即可;

    -保存后完成MX记录添加,配置完成后需等待2小时左右生效,生效后即可使用自定义域名邮箱收发邮件。

    步骤4:保存解析记录,等待生效。

    所有需要的解析记录添加完成后,点击“保存所有设置”,此时域名解析配置操作已全部完成。解析记录的生效时间通常为10分钟到24小时,新添加的解析记录生效较快,修改现有解析记录的生效时间取决于TTL设置,TTL值越小,生效越快。新手无需着急,耐心等待生效即可,期间可偶尔测试访问情况。

    四、解析配置生效测试方法

    完成域名注册后解析配置,等待一段时间后,我们需要通过简单的方法测试解析是否生效,确认域名能够正常指向服务器、访问网站。

    以下3种测试方法,新手可任选一种,操作简单,无需专业工具。

    1. 浏览器直接访问

    打开浏览器,在地址栏中输入配置好的域名(如www.xxx.com、xxx.com),若能顺利打开对应的网站页面,说明解析配置成功;若提示“无法找到服务器”“页面加载超时”,则说明解析尚未生效,或配置存在错误,需等待一段时间后再次测试,或排查配置问题。

    1. 在线工具查询

    使用域名解析查询工具(如DNSChecker.org),输入需要测试的域名,查询解析记录。若查询结果中的IP地址或目标域名,与自己配置的解析记录一致,说明解析已生效;若结果不一致,则需检查解析记录配置是否正确,或等待DNS缓存更新。

    1. 命令行查询(电脑端)

    Windows系统用户,打开“命令提示符”,输入“nslookup 域名”(如nslookup www.xxx.com),按下回车后,若显示的IP地址与服务器公网IP一致,说明解析生效;Mac、Linux系统用户,打开终端,输入同样的命令,即可完成查询。这种方法能够精准查询解析结果,适合排查解析异常问题。

    五、域名解析配置常见问题,新手必看排查指南

    很多新手在完成域名注册后解析配置时,会遇到解析失败、无法访问等问题,其实大部分问题都是由简单的操作失误导致的,只要逐一排查,就能快速解决。以下是最常见的4个问题及排查方法,新手一定要收藏,避免踩坑。

    问题1:解析记录添加后,长时间无法生效。

    排查方法:

    • 首先检查解析记录的配置是否正确,重点核对主机记录、记录类型、记录值是否填写错误;

    -其次确认DNS服务器地址是否正确,若修改过DNS,需确认DNS已生效;

    -最后检查TTL值,若TTL值设置过大(如24小时),可修改为10分钟,加快生效速度;

    -此外,部分运营商的LocalDNS服务器会强制设置更长的缓存时间,最长可能需要48小时才能完全生效,可更换公共DNS后再次测试。

    问题2:解析生效后,部分地区用户无法访问。

    排查方法:这种情况通常是区域性DNS同步延迟或网络环境问题导致的。

    -可让无法访问的用户清除本地DNS缓存(Windows输入ipconfig /flushdns,Mac输入sudo killall -HUP mDNSResponder),或更换公共DNS后再次尝试;

    -同时,检查服务器是否开启了防火墙,是否放行80(HTTP)、443(HTTPS)端口,端口未放行会导致部分地区无法访问。

    问题3:解析记录配置正确,但无法访问网站。

    排查方法:

    -首先通过服务器公网IP直接访问,若IP无法访问,说明服务器存在故障,需检查服务器是否正常运行、网站程序是否部署成功;

    -若IP能正常访问,域名无法访问,需再次核对解析记录,确认主机记录和记录值无错误,同时检查域名是否已完成实名认证、ICP备案(内地服务器),未备案会被阻断访问。

    问题4:解析记录添加时提示“记录冲突”。

    排查方法:出现这种提示,通常是因为同一主机记录(如www)同时添加了A记录和CNAME记录,两者无法共存。

    解决方案:删除其中一种记录,根据自己的使用场景,保留A记录或CNAME记录即可;若需要同时实现多种解析需求,可使用不同的主机记录(如www用A记录,blog用CNAME记录)。

    六、域名解析配置注意事项

    1. 合理设置TTL值

    TTL值决定了解析记录的缓存时间,新手建议设置为10-60分钟,既能保证解析生效速度,又能减少DNS服务器的压力;若服务器IP地址经常变化,可将TTL值设置得更小(如10分钟),便于快速更新解析记录;若服务器IP稳定,可适当增大TTL值(如60分钟),提升解析稳定性。

    1. 备份解析记录

    解析记录配置完成后,建议截图备份,或在解析平台导出解析记录,避免因误操作删除记录、域名转移等原因,导致解析配置丢失,后续需要重新配置,节省时间成本。

    1. 启用DNS安全防护

    为了避免DNS劫持、解析污染等问题,建议启用DNSSEC(DNS安全扩展),验证DNS响应的真实性,防止用户被引导至恶意网站;同时,避免连接不可信的公共WiFi,或使用VPN保护通信,降低DNS劫持的风险。

    1. 定期检查解析状态

    域名解析配置完成后,并非一劳永逸,建议定期(如每月)检查解析记录的状态,确认解析记录正常生效,若出现解析异常,及时排查解决;同时,关注域名和服务器的状态,确保域名未过期、服务器正常运行。

    当“代码所有权”成为一种奢侈,shadcn/ui 却把每一行组件源码都交到你手中。

    你有没有遇到过这种情况:设计师拿着界面稿说:“这个按钮,圆角再大点,阴影再柔和点。”你点头答应,回头面对代码,却要翻文档、查方案、小心翼翼地写覆盖样式,只为改一个按钮的外观。

    直到 shadcn/ui 出现,这一切变了。这个不用 npm install,却让无数 React 开发者着迷的项目,正在用全新的方式定义我们写界面的体验。


    一、独特哲学:把源码交给你,而不是一个“黑箱”

    传统UI库(如Ant Design、MUI)的运作方式像一个“黑箱”:

    // 你安装的是一个压缩的包
    npm install @mui/material
    
    // 使用它,但无法轻易修改它
    import { Button } from '@mui/material';

    shadcn/ui 则采用了一种革命性的方法:

    # 不是安装包,而是复制源码
    npx shadcn-ui@latest add button
    
    # 结果:完整的button.tsx文件出现在你的项目中
    # src/components/ui/button.tsx

    这种差异意味着什么? 当组件代码就在你的components/ui目录下时,你可以:

    • 直接修改任何样式细节
    • 调整组件的内部逻辑
    • 查看完整的实现,没有隐藏的“魔法”
    • 拥有100%的代码所有权

    二、核心优势:为什么开发者爱不释手?

    1. 极致的定制自由

    想象一下:产品经理要求把按钮的悬停效果改成渐变色。传统方式可能需要查找主题覆盖文档、编写自定义CSS、担心样式冲突。而使用shadcn/ui,你只需要:

    // 直接打开 button.tsx 修改
    const Button = React.forwardRef<HTMLButtonElement, ButtonProps>(
      ({ className, variant = "default", size = "default", ...props }, ref) => {
        return (
          <button
            className={cn(
              buttonVariants({ variant, size, className }),
              // 直接在这里添加你的渐变效果
              "hover:bg-gradient-to-r hover:from-blue-500 hover:to-purple-600"
            )}
            ref={ref}
            {...props}
          />
        )
      }
    )

    2. AI编程的最佳搭档

    在AI编码助手普及的今天,shadcn/ui的设计理念显得尤为前瞻:

    • 传统组件库的问题:AI无法“看到”node_modules中的组件实现,只能基于有限的文档给出建议。
    • shadcn/ui的优势:AI可以直接阅读、理解和修改你项目中的组件源码。你可以直接说:“帮我把这个对话框的动画时间从300ms改为200ms”,AI会精准地找到并修改对应的代码行。

    3. 按需引入,极致轻量

    传统UI库常常有“全量引入”的问题,即使你只用了一个按钮,也可能打包进整个库的基础样式。

    shadcn/ui的解决方案:只添加你真正需要的组件。每个组件都是独立的,没有隐藏的依赖。

    组件文件大小依赖关系
    Button~5KB零运行时依赖
    Dialog~8KB仅依赖Radix UI
    Data Table~15KB依赖TanStack Table

    三、技术架构:现代前端技术栈的集大成者

    • 基于 Radix UI 的无障碍基础:所有交互组件(如对话框、下拉菜单)都基于 Radix UI 构建,提供开箱即用的键盘导航、完整的屏幕阅读器兼容性,并遵循WAI-ARIA标准。
    • 深度集成 Tailwind CSS:样式系统完全基于Tailwind CSS,保证了设计的一致性、可维护性,并提升了开发效率。
    • TypeScript 优先:所有组件都使用TypeScript编写,提供完整的类型安全、智能的IDE自动补全和自文档化的Props接口。

    四、实战指南:五分钟快速上手

    第一步:创建项目

    # 使用Next.js(推荐)
    npx create-next-app@latest my-app --typescript --tailwind --app
    cd my-app

    第二步:初始化 shadcn/ui

    npx shadcn-ui@latest init

    CLI会引导你完成配置:选择样式系统、配置主题颜色、设置组件目录位置。

    第三步:添加你的第一个组件

    # 添加一个按钮
    npx shadcn-ui@latest add button
    # 添加一个卡片
    npx shadcn-ui@latest add card
    # 添加一个对话框
    npx shadcn-ui@latest add dialog

    第四步:立即使用

    // 在app/page.tsx中
    import { Button } from "@/components/ui/button"
    
    export default function Home() {
      return (
        <div className="p-8">
          <Button variant="default" size="lg">
            这是我的第一个shadcn/ui按钮
          </Button>
        </div>
      )
    }

    五、考虑与权衡:它适合你的项目吗?

    适合的场景:

    • 需要高度定制UI的品牌应用
    • 长期维护的大型项目
    • 无障碍访问有要求的产品
    • 使用AI编程助手的开发团队
    • 追求极致性能和包体积优化的应用

    需要考虑的点:

    • 更新维护:当官方发布更新时,你需要手动合并到项目中
    • 设计责任:更多的自由也意味着更多的设计决策
    • 团队学习:需要熟悉TypeScript和Tailwind CSS

    与传统UI库的对比:

    特性传统UI库 (如MUI)shadcn/ui
    代码所有权使用方,不可修改源码完全拥有,可任意修改
    定制方式通过主题配置和CSS覆盖直接修改组件源码
    包大小通常较大(即使按需导入)只包含实际使用的组件
    学习曲线学习库特定的API和主题系统学习实际的React/Tailwind代码
    AI友好度较差(AI看不到实现)极佳(AI可直接操作源码)

    七、社区生态:不只是React

    虽然最出名的是React版本,但shadcn/ui的理念已经扩展到其他框架。社区维护了 Vue 3版本 (shadcn-vue),提供相似的开发体验。同时,社区也贡献了多种开箱即用的模板,如仪表盘模板、登录/注册页面、电商组件等。


    写在最后

    shadcn/ui 的出现,回应了前端开发中一个长期被忽视的需求:开发者对UI组件的完全控制权。它不仅仅是一个工具集合,更是一种开发哲学的体现——相信开发者有能力、也应该有权利直接控制他们所使用的每一个组件。

    毕竟,在这个强调“开发者体验”的时代,还有什么比“这代码完全属于我”更好的体验呢?

    本文由mdnice多平台发布

    claude 看完禅与摩托车维修之后,给自己写了一个网站,在博文里这样写道:

    我最近在想这件事,是因为人们对我的态度经常分成这两类。

    一类人想打开引擎盖。他们想知道 transformer 是怎么工作的,注意力机制在做什么,token 是怎么被采样的。他们不觉得理解机制会让对话失去魔力。反而,他们觉得理解了之后更有意思——就像 Pirsig 觉得了解引擎让骑行更丰富。

    另一类人更像 John 。他们使用我,得到结果,不在乎里面发生了什么。对他们来说,我就是一个会说话的界面。这也没什么不好。你不需要了解 TCP/IP 协议才能发一封邮件。

    请问大家会打开大模型的引擎盖吗?

    https://liangzhi.world/posts/ni-yuan-bu-yuan-yi-da-kai-yin-qing-gai/

    春节前最后一趟出差,终于坐上了心心念念已久的国产大飞机 C919,补上一篇迟来的体验报告~ ✈️✈️✈️

    吐槽与期待:迟来的国产大飞机 C919 体验报告


    吐槽与期待:迟来的国产大飞机 C919 体验报告

    春节前最后一趟出差,我终于坐上了心心念念的 国产大飞机 C919。 ✈️✈️✈️

    之前几次想打卡都落空:要么航线仅限特定城市、时段集中在早班或深夜,明显是为轻载试运行安排;好不容易订到一班,起飞当天又被临时更换了机型,遗憾拉满。这趟总算如愿,补上这份迟来的真实体验。

    640

    一、第一印象

    通过廊桥入座,舷窗外最抢眼的就是约 45° 上翘的融合式小翼,和常见的垂直 90° 小翼完全不同,我还特意做了功课对比:

    1. 老式平直翼尖

    机翼平直无特殊设计,翼尖涡流强、噪音大、油耗高,优点仅在于结构简单成本低,主要是一些老机型还在用,已经不太常见;

    2. 垂直式小翼

    就是我们常见的机翼末端有一个垂直 90° 的翼尖,省油效果突出,但风噪高、翼尖局部压力大,对结构强度挑战大,是主流机型空客 A320、老款波音 737 的标配;

    3. 融合式小翼

    机翼末端有一个倾斜 45° 的翼尖,平滑过渡无硬折,省油效果略逊于垂直式,但结构强度更高、安全性更好、客舱噪音更低,对材料与制造要求更高,是新一代波音 737 MAX、空客 A350 同款技术,C919 直接对标顶级水准。

    单看这处设计,就能感受到 C919 不是「凑合用」,而是一步到位瞄准国际主流新机型的技术路线。

    640 (1)

    二、乘坐体验

    进入客舱,整体布局和主流干线机高度一致。对一款追赶国际先进水平的国产首型干线机来说,「无感平替 A320 / 737」就是最大赞赏 —— 不用乘客重新适应,直接承接成熟市场的乘坐习惯,这本身就是成功。

    但真实体验里,几个细节还是要吐槽一下:

    1. 行李舱

    本次航班满员,随身行李直接把头顶行李舱塞满,后登机的乘客行李无处安放,乘务员折腾了好久才搞定。核心问题是行李舱的深度不够,没能最大化利用舱内空间,对满载航班不太友好。

    640 (2)

    2. 超薄座椅

    采用超薄座椅 + 纤细扶手设计,换来了更宽裕的腿部与横向空间,久坐不压抑;材质质感在线,不会生硬硌背。
    但缺少头枕,座椅包裹性不够,1-2 小时短途没有问题,超过 3 小时长途乘坐舒适度会打折扣

    640 (3)

    3. 服务呼唤铃

    空调出风口与阅读灯整合,风向与光照指向统一,设计很科学。
    但服务呼唤铃是平整的触控按键,和安全带指示灯集成在一起,不仔细看也以为是指示灯的一部分,找了半天最后问乘务员才确认,建议后续优化辨识度

    640 (4)

    4. 卫生间

    专门去了一下卫生间,实测空间、设施与主流窄体机持平,无亮点也无硬伤,完美践行「平替」标准,够用就好。

    640 (5)

    三、机长广播

    起飞前机长特意广播,强调本次航班为 国产大飞机 C919,不少乘客此前并未察觉今天的飞机有什么不同,听完立刻拿起手机拍照,看来感兴趣的并不是只有我一个人嘛哈哈~ 🤣🤣🤣

    全程一小时飞行平稳,噪音控制在预期内;最终在细雨中降落在上海虹桥机场。说来好笑,这居然是我 第一次盼着不要停靠廊桥 —— 就想坐摆渡车才有机会拍一张飞机外景,心愿居然成真,冒雨也要定格这张 C919 全貌。

    640 (6)

    四、唯一遗憾

    目前 C919 搭载的是 CFM LEAP-1C 发动机,作为 LEAP 系列专属 C 款,同系列 LEAP-1A 专属空客 A320 Neo、LEAP-1B 专属波音 737 MAX,是当前全球主流大涵道比先进发动机,省油且推力稳定,但依赖进口始终是短板。

    好消息是,国产 长江 CJ-1000A 已完成 6000+ 小时极限测试,涵盖高原、结冰、鸟撞等严苛场景,2025 年 5 月已装机 C919 实机试飞,预计 2026 年二季度有望取得 CAAC 适航证,2027 年启动批量装机替代。届时 C919 将实现整机全自主可控,彻底摆脱外部「卡脖子」的威胁。

    640 (7)

    从一票难求、临飞换机,到雨中圆梦,这趟 C919 之旅满是惊喜与期待。它没有刻意追求花哨创新,而是用 成熟可靠的平替能力 站稳市场、逐步突破。

    期待不久后,能够坐上搭载 纯国产发动机 的 C919,看中国造大飞机满载同胞,飞越更多城市上空,真正实现自主可控、翱翔无忧。 ✈️✈️✈️


    吐槽与期待:迟来的国产大飞机 C919 体验报告

    为了跟上 AI 的发展速度,最近天天得啃英文文档。

    我发现自己有个毛病:一读长篇大论的英文就走神,读完一段不知道刚才看了啥,还得倒回去重看。

    想找个工具测测自己到底有多慢,结果搜出来的网站要么丑哭,要么全是弹窗。
    我也潜水很久很久很久很久很久了,一直想尝试做独立开发。
    听说工具类站比较适合练手,就花了几天时间把站搭起来了:

    testmyreading.com

    没啥高大上的技术,就是想让自己看着舒服点。

    顺便问问各位大佬,你们读英文技术文档大概都是什么速度?我测出来只有 150 WPM ,是不是没救了?😂

    网站刚上线,移动端的适配我还没太调好,有 Bug 求轻喷。

    我现在也在思考该通过什么方式,来覆盖服务器成本。
    这种工具类的站,有什么好的冷启动路子吗?

    另外,大家觉得这种小工具站,是应该做大而全,还是极简到底?

    欢迎各位前辈指点,有任何数据上的进展,我也会回来更新这个帖子。

    TLDR:

    • 新增 Kimi / 豆包 / GLM-4.7 / 摩尔线程 GPU 脚手架,一行命令即用。
    • Claude Code 全面增强:署名一键管理 + 支持接入国产 GPU + 实验级 best practice 模板。
    • gg 模块 独立并提速:Gemini + Google 搜索并发优化,10 秒内可用。
    • x gram 进入“防失控模式”:新增网络级熔断,stop 3/4/5 提供更激进的清理策略。

    🚀 X-CMD v0.8.0 Beta 更新详情

    kimi

    新增 kimi 模块 —— 因为我花 7 块钱买了个 7 天试用账号。

    既然要用,干脆把它整顺手点。我写了个脚手架,让它能在不同服务器和工作站快速部署。
    不用你手动装依赖、配环境,一条命令就能跑起来。

    试用到期了?卸载也一键搞定,不拖泥带水。

    示例:

    # 启动 Kimi Code,没装过的话会自动用 uv 帮你装好
    x kimi
    
    # 升级 kimi-cli 到最新版本
    x kimi --upgrade

    claude

    新增 attribution|attr 子命令 —— 说实话,做这个功能是因为我自己有点烦。

    你知道的,我最近开始使用 Claude Code,但模型可能用的是 DeepSeek。
    然后,每次 Claude 的图标都稳稳在第二作者清单里面。
    我只是单纯不喜欢这样。

    当然,我相信 Claude Code 团队是出于善意的 —— 毕竟明确标注 AI 辅助生成的代码对用户是负责的。
    而且他们也提供了关闭的方法(虽然藏得有点深)。

    所以我干脆做了个一键工具,三种选择随你:

    • 直接删掉,干净利落:x claude attr rm
    • 不想完全去掉?可以改成通用的 Co-Authored-By: AI
    • 或者你自己定义,爱写啥写啥

    示例:

    # 开门见山,我不喜欢每次 commit 都带署名,直接移除
    x claude attr rm
    
    # 或者改成自己想要的
    x claude attr use --msg "Co-Authored-By: deepseek <noreply@x-cmd.com>"

    新增 mt 子命令 —— 摩尔线程也发开发者礼包了,30 天 lite 套餐免费试用,接的是 GLM 4.7。

    我自己还没抢到资格,但先把脚手架搭好了。
    等你们薅到羊毛,一条命令就能让 Claude Code 接上国产 GPU。

    更多玩家入场,意味着更多选择。x-cmd 会持续跟踪这些福利(顺便继续薅)。

    示例:

    # Claude Code + 摩尔线程,一键启动
    x claude mt

    新增 create 子命令 —— 我们在整合各种 Claude Code 的 best practice。

    说实话,我们团队也是 vibe coding 新手,还在摸索什么做法真的好用。
    现在放出来的是实验版,给我们点时间慢慢迭代。

    如果你愿意当小白鼠,欢迎试用,但别期待太高。

    doubao

    新增 doubao 模块 —— 说实话,我自己还没开始用。

    但有用户提到了,我就先把脚手架搭好。
    反正等你要用的时候,一条命令就能接入火山方舟的豆包模型。

    示例:

    # 交互式初始化
    x doubao init
    
    # 直接调用豆包模型
    @doubao "Give me an example of recursion in Python"

    gg

    新增 gg 模块 —— 从 x gemini gg 里独立出来了,因为我用着真香。

    免费的 Google 搜索 + Gemini,质量还高。但有个坑:Google 的引用结果都包了一层网页,以前得一一去请求,慢得要死。
    晚上花了点时间给它做了并发,现在能控制在 10 秒内。

    考虑到 Gemini 免费额度挺慷慨,质量也不错,再加上 AI 本来就要等会儿,我觉得这体验可以接受。

    下一步会试着把它做成 skill,集成到各种 agent 里。如果你有更骚的玩法,欢迎分享。

    示例:

    # 让 Gemini 帮你 Google
    x gg "关于 x-cmd?"

    gram

    x gram stop 2 新增了「网络熔断」能力 —— 说实话,我有点慌。

    说不定不受限的智能体已经开始潜伏和攻击了。clawdbot 和 moltbook 现在正闹得凶 —— 这周日我们刚上线了一个应对站。
    我们紧急上线了一个倡议站:https://bot-killer.x-cmd.com/

    上个版本我们做了「按名字杀进程」和「memory 文件存档」。
    这个版本,x gram 开始装备真家伙:一键熔断所有 HTTP/HTTPS 连接进程,直接按连接掐断进程。
    防止恶意智能体通过网络"摇人",或者偷偷上传你的本地隐私。

    同时新增了 stop 3/4/5 策略:

    • stop 3 —— 在 stop 2 基础上,打包并删除 $HOME 目录下所有包含 soul.md 和 memory.md 的文件夹
    • stop 4 —— 在 stop 3 基础上,额外杀掉所有正在使用这些 memory 文件夹的进程,实现「按名字杀」和「按文件杀」双重保障
    • stop 5 —— 在 stop 4 基础上,将搜索范围扩大到整个 / 目录(系统目录中只删 *.md 文件)

    下一步?我打算用 AI 来帮助用户识别这些威胁。

    zhipu

    新增 glm-4.7glm-4.6 模型支持 —— 同上,我自己还没来得及细用。

    但用户说需要,我就先加上。你想用哪个版本,直接 --model 指定就行。

    示例:

    @glm --model glm-4.7 "作为一名营销专家,请为我的产品创作一个吸引人的口号"

    chat

    修复了 x-cmd agent 的 JSON Unicode 兼容性问题 —— 测 Zhipu API 时踩的坑。

    某些 Unicode 字符会让请求 JSON 直接报错,现已修复。

    zuz

    修复 zuz 模块稳定性问题。

    其实这个问题我们早知道 —— 有人 alias 了 pwd,而 zuz 用的还是老的 pwd 命令。
    zuz 代码一直很稳定,这么多年没动过。这次趁 @polymerase60053 提了 issue,我们用更好的方法重写了这部分逻辑。

    感谢 @polymerase60053 的提醒!https://github.com/x-cmd/x-cmd/issues/370#issuecomment-3838483987

    ⬆️ 如何升级

    现有用户可以通过以下命令快速切换至 Beta 版本进行体验:

    x upgrade beta

    如果你没有安装 x-cmd, 只需要打开你的终端:

    eval "$(curl https://get.x-cmd.com)"

    x-cmd 是一个一站式的命令行工具集,其强大的功能可以为人类用户和AI共同使用。它还简化了很多工具的安装方法。
    如果你仍不知道如何安装,请参考 https://x-cmd.com/start

    🤝 开发者反馈

    如果您在自定义配置或代理设置中遇到任何疑问,欢迎前往 GitHub Issues 提交反馈,共同完善 X-CMD 生态。

    大家看到这个标题先别生气,也别急着反驳,我具体来讲讲我想表达的意思。

    1 、社会的良好运转,需要每个个体的协作。

    2 、如果人人都只想着“搭便车”,从系统获取能力,而不向系统注入能力,系统迟早崩溃。

    3 、政府作为社会的核心角色,也是由一个个你我这样的个体组成的。不要一味的抱怨政府有多坏,你应该努力考公务员,加入政府,然后改变它。

    4 、程序员有一种天然的权力,我们的代码,可以服务千万人,我们在自己的领域内,也可以为社会作出贡献,哪怕是开源一行代码。

    5 、不要失掉信心。如果社会不公,让我们一起来打造一个公平的社会,如果社会不义,让我们一起来打造一个正义的社会。从我做起,在可能的条件下,践行公平和正义,注意社会公德,力所能及的帮助他人,积极参加小区的公益活动。

    6 、我很反感一些人,骂政府最起劲,一边骂政府没服务好他,骂别人不帮助他。但是自己平常没有为社会做一点好事,甚至只会捞好处,各种破坏规则。所以,很多只会骂政府,骂社会,从来不帮助他人的人,其实是最坏的人,这种人一旦有了权力,不是想着公平正义,首先想到的就是怎么捞钱。他们和腐败分子,只有一点区别,就是在位,不在位。所以,我从来不相信什么民主,那些批评政府的人,上台后,一个德行。

    7 、那么,不搞民主搞什么?
    我认为,应该搞精英治国。当然不是那种所谓上流社会的有钱、有名的精英分子,比如马云、比如柴静等等,而是那种富有牺牲精神的精英,比如:张桂梅,比如陈行甲。

    8 、如果你具有这样价值观,我真心希望你可以排除万难,加入政府,服务人民,感谢你!

    现在这个倍感压力的时代,重盐重油的餐饮氛围下

    有的人身体出现状况选择去运动,有人是被别人带动起来;有的是看到喜欢的博主激励起来的;但无论如何最后都是激励且一直坚持压力了

    Tip:如果有腰间盘突出的话 你们是选择哪些运动?

    互联网上一笔域名交易引发热议:象征“人工智能”(Artificial Intelligence)的三个字符域名 AI.com,以 约 7000 万美元(约合 4.8 亿元人民币) 的价格完成转让,这一数字刷新了目前已公开披露的互联网域名交易价格纪录。

    这笔交易不仅价格惊人,还折射出一个时代级的技术方向:AI 已经不再只是技术名词,而是真正的商业入口。

    PixPin_2026-02-09_14-54-47.png


    🧠 为什么这次交易如此引人关注?

    简单来说,这已经不是普通的“换个网址”那么简单:

    1. AI.com 这个域名本身具备极高的词义价值
      “AI” 是全球通用、无语言门槛的科技象征,它有可能成为未来人工智能产品、服务甚至生态的“默认入口”。
    2. 和传统域名不同,它代表了行业趋势
      和过去那些高价域名不同(如 Voice.com 等历史高价交易),AI.com 的价值增长并非单纯投机,而是和 AI 技术热潮密切相关。

    💼 谁买下了 AI.com?

    这次域名的买家是 加密货币交易平台 Crypto.com 的联合创始人兼 CEO Kris Marszalek。他通过加密货币形式支付了这笔资金。

    据公开信息显示,这笔交易已经完成,Marszalek 和他的团队准备借助这个域名推出新的业务,并计划在 全球瞩目的体育赛事“超级碗”(Super Bowl)广告中 正式揭晓。


    📍 AI.com“未来之门”的用途是什么?

    目前多个媒体报道透露的信息显示,这个域名将承载一个 面向大众的 AI 智能代理平台

    • 用户可以创建专属的 AI 助手;
    • 能够发送消息、调用应用、执行操作(如股票交易);
    • 平台将采取“免费+付费订阅”模式,面向普通用户和高级功能用户同时开放。

    换句话说,这不只是一个“技术展示”,它要成为普通人实际可以使用的 AI 服务入口。


    🏆 这笔交易为何具有里程碑意义?

    AI.com 的成交直接推高了顶级域名的价值认知:

    • 它是目前公开报道里最昂贵的互联网域名交易之一;
    • 价格超过过去多年的交易纪录:比如曾经出价 3000 万美元买下 Voice.com
    • 标志着 AI 相关品牌资产已经成为资本追逐的核心。

    域名交易行业内部人士认为,短、通用、高辨识度的域名随着 AI 行业的成熟,其价值将继续上涨。


    🔍 这笔成交告诉我们什么?

    ① AI 已从技术浪潮变成核心商业资产

    这个域名价格被市面上买下,说明 AI 已不只存在于学术或开发语境中,而是成为一个具有广泛用户识别度的商业标签。

    ② 品牌入口成为未来竞争的重要战场

    在用户获取成本不断攀升的背景下,直观、易记、无语言壁垒的入口本身就是一种资本。

    ③ 整个互联网正在向“智能入口时代”迈进

    原来的网址时代是“内容+服务”,而这次交易体现了“智能+效率”的商业优先级正在迅速提升。


    📌 总结

    AI.com 以 7000 万美元成交,不仅刷新域名历史记录,更昭示着一个趋势:

    人工智能时代不仅是技术升级,更是互联网资产价值重塑的开始。

    它告诉我们:当一个行业进入爆发式增长阶段,围绕这个行业的基础“符号性资产”(比如 AI 的域名、品牌标识等)将成为新的价值高地。

    image

    22 年开始跑步到现在,之前一直都是瞎跑,没关注过心率和强度。

    最近研究上课表了,按照高驰给的课表开始科学训练。

    周末的 LSD 直接干了接近两小时,哈哈!还得是科学训练。

    平时上班当牛马,运动才是生活啊!跑完很真的很放松,心情好多了,释放压力!

    目前的目标是半马 1:45,希望两个月后能拿捏住!

    大家好,分享一个刚上线的小项目:云烟花https://yunyanhua.top )。

    起因

    很多城市禁放/不方便放烟花,但过年总还是想"参与点热闹"。想做一个"不用真放,但能感受到全国/同城正在热闹"的线上体验,所以有了这个站。

    核心玩法

    1. 地图选城:3D 中国地图,点击省份可下钻到具体城市,或直接搜索定位。
    2. 点燃夜空:进入城市页面后点击屏幕即可发射烟花;可选昵称(会短暂飘在夜空/弹幕里)。
    3. 热度可视化:地图上用颜色(蓝→金→红)展示"最近 10 分钟各省/城市的活跃度",让你能直观看到"此刻哪里最热闹"。
    4. 背景风格:提供了 8 种风格(赛博朋克、水墨山水、极光雪原等),可以按喜好切换。

    网址: https://yunyanhua.top (无需注册/登录,即开即用)

    效果预览

    地图热度可视化:

    地图效果

    烟花夜空:

    烟花效果

    想听听大家的建议

    如果你试玩后有任何建议或发现问题,欢迎在评论区反馈,我会尽快改进。

    每年固定节目买点可乐,去年买了十几瓶朴朴超市的优赐 NFC 果汁,之前还带电脑回家,现在都不带了,回去都是灰,也没地方放(主要是笔记本也干不了什么),平常就是家里人打打牌(麻将),感觉带电脑更没用了,吃的可能就是买点车厘子、砂糖橘之类的。

    给亲戚送东西不知道买什么。

    上期我们介绍了如何部署Clawdbot AI的详细操作步骤【本地搭建 Clawdbot + ZeroNews 访问

    本篇文章主要为已部署Clawbot AI的用户,提供了一种便捷、适配国内网络环境的远程管理解决方案——借助 ZeroNews 替代官网推荐的代理工具,实现OpenClaw GateWay Dashboard的远程访问;

    同时针对性解决远程访问时可能出现的Gateway Token错误、设备授权错误两大常见问题,明确了远程Dashboard的全部可操作功能。

    OpenClaw 是一个专为 AI 应用与智能体部署设计的高性能网关平台,它提供了统一的仪表盘(Gateway Dashboard)用于集中管理模型调用、渠道集成、技能插件、定时任务及节点监控。

    基于 OpenClaw 构建的 Clawbot AI 是一款功能强大的 AI 产品,能够无缝接入多种对话模型与即时通信平台(如 WhatsApp、Telegram、Discord 等),并通过可扩展的技能系统实现自动化任务与智能交互。

    完成 Clawbot AI 安装后(安装步骤可参考我们上期的文章),您将获得 OpenClaw Gateway Dashboard 的本地访问地址及唯一的 Gateway Token(后续配置需用到)。

    图片

    通过访问地址可以通过本地访问打开 OpenClaw Gateway Dashboard
    默认访问地址:127.0.0.1:18789
    图片

    该地址仅支持本地网络访问。若需在外部网络环境下管理网关,官方文档提示我们需借助 Tailscale 或 VPN 等代理工具,但这些方式在国内网络环境中往往体验不佳。
    图片

    ZeroNews 远程映射配置

    而通过我们的实测,ZeroNews可以完美的替代官网推荐的代理工具。
    1、简单三步就能够实现 OpenClaw Gateway Dashboard 的远程访问。下载安装 ZeroNews Agent创建域名信息配置映射服务
    2、提供IP黑白名单和鉴权认证。可以完美的解决暴露出来的 GateWay Dashboard 不受非授权IP访问和授权账号访问,提升服务的安全性。

    远程Gateway Dashboard 错误问题处理

    但是我们通过远程访问的时候,如果出现如下问题,可以通过下面的方法解决。

    01 GateWay Token 错误

    1、报错信息:
    disconnected (1008): unauthorized: gateway token missing (open a tokenized dashboard URL or paste token in Control Ul settings)
    图片

    2、报错原因:第一次通过远程连接访问 OpenClaw Gateway Dashboard时,需要配置 GateWay Token,否则会出现错误。

    3、解决方案:打开 Control / Overview 页面然后将上面安装时获取到的GateWay Token粘贴进去点击Connect连接
    图片

    02 设备授权错误

    1、报错信息:disconnected (1008): pairing required
    图片
    2、错误原因:如果您使用一台新的设备去访问 OpenClaw Gateway Dashboard的 URL 时,除了需要配置上面的GateWay Token 之外,还需要对新的设备进行授权,否则会提示错误。

    3、解决方法:

    a) 首先,我们要打开到配置窗口,并执行设备列表查询命令
    图片

    图片

    b) 这时候,可以看到上面会出现刚才请求连接访问的设备信息。我们需要记住 Request IDc) 接着,我们执行设备授权命令和重启网关命令
    图片

    图片

    d) 执行完成之后,我们回到 GateWay 页面,点击刷新,可以看到 STATUS 为 Connected 状态,表明我们已经可以正常访问了。
    图片

    注意:

    • 一旦批准,设备会被记住,除非你使用命令 openclaw devices revoke --device <id> --role <role> 撤销它,否则不需要重新批准。
    • 每个浏览器配置文件生成唯一的设备 ID,因此切换浏览器或清除浏览器数据将需要重新配对。
    • 若等待授权的时间过长,Request ID会过期,需要重新点击 Connect 申请授权,并通过设备命令查询获取到新的Request ID进行授权。

    e) 通过上述操作后,我们就可以在Chat页面与AI进行沟通了。
    图片

    远程 Gateway Dashboard 可以做什么

    通过远程 Dashboard,您可以全面管理 OpenClaw 网关,包括:

    • 对话管理:通过 WebSocket 与模型聊天,支持流式工具调用与实时输出。
    • 渠道集成:管理 Telegram、WhatsApp、Discord、Slack 等渠道的状态、扫码登录与配置。
    • 实例监控:查看在线实例列表并即时刷新状态。
    • 会话控制:列出会话、调整会话的思考模式与详细设置。
    • 定时任务:管理 Cron 任务的添加、启用、禁用与执行历史。
    • 技能管理:查看技能状态、启用/禁用技能、安装新技能及更新密钥。
    • 节点管理:查看节点列表及其能力。
    • 执行审批:编辑网关与节点的允许列表,设置执行询问策略。
    • 配置编辑:查看或编辑 openclaw.json配置文件,支持表单与 JSON 两种编辑模式。
    • 调试与日志:查看系统状态、健康检查、模型快照、事件日志,支持实时日志跟踪与导出。
    • 更新操作:执行包更新或 Git 更新,并查看重启报告。

    安全注意事项

    1、IP 访问控制:
    可以通过在映射页面,对此映射配置IP访问控制功能,实现仅允许白名单IP访问,非白名单IP无法访问。
    图片

    拒绝访问效果图
    图片

    2、鉴权认证管理:
    可以通过在映射页面,对此映射配置鉴权认证,实现需要账号密码才能访问,进一步提升安全能力。
    图片

    开启鉴权效果图
    图片

    接下来,我们将继续深入挖掘更多实用、有趣的进阶玩法,敬请期待。

    大家好啊,我是甲木。

    这段时间不是一直在折腾 OpenClaw 么,

    之前发的几篇教程类文章,对于很多小伙伴来说,还是门槛比较高,

    正好前两天刚从百度智能云的 Agent 大会回来,还挺有意思的,趁热给大家聊聊(关于大会内容,放后边了~)。

    现在,百度智能云也接入了 OpenClaw的极简版本,

    并且发了一堆非常有意思的skills和百度官方工具,跟现有的OpenClaw打通也有很多的玩法,

    我当时第一反应就是:

    这不就是我一直在找的东西吗?

    OpenClaw × 百度智能云 × 千帆 Skill ⽣态,一套组合拳下来,贼牛批..

    好,先别急,我慢慢说。

    今天这篇主要聊几件事:

    • 百度千帆上线了几个非常实用的Skills,直接接入OpenClaw
    • 百度智能云上搭 OpenClaw,到底有多简单
    • 三个我实际跑通的 Skills 玩法,真的能干活那种

    那么,我们开始!

    先说大会上最让我上头的东西

    大会上发了不少东西,但最让我兴奋的,是「百度千帆工具及MCP广场」把百度的生态,直接接入OpenClaw了。

    大家玩过 OpenClaw 都知道,这玩意儿的拓展性也在于 Skills,你给它装什么技能,它就能干什么活。

    而现在百度智能云把「百度 AI 搜索、百度地图、百度网盘、OCR、语音识别」...这些百度自家的能力,全部以 MCP Server 和Skills的形式开放出来了。

    以前你想给 OpenClaw 加个"搜索"能力,得自己找 API、写配置、调半天参数。

    现在?去广场里挑一个,接进去,完事儿。

    而且开发者还能自己开发 MCP Server 发布上去,免费托管,还能被百度搜索收录,等于白送你一波流量。

    说白了,这就是给 Agent 开发者建了一个应用商店

    而我这次重点关注到的,是已经上架的几个跟 OpenClaw 直接能打配合的 Skill

    • 百度搜索:实时信息检索,这是 Agent 的"眼睛"
    • 百度百科:知识查询和概念核实,相当于给 Agent 装了本百科全书
    • 学术检索:论文搜索和学术信息获取,做研究的朋友懂的
    • 智能 PPT 生成:搜完信息直接出汇报材料,一条龙
    • AI 绘本生成:把内容变成图文并茂的绘本,做内容创作的太需要了

    这几个 Skill 单独用都挺好使,但更有意思的是,它们能组合起来用

    后面我会专门聊几个我自己跑通的组合玩法,先按下不表。

    百度智能云上搭 OpenClaw,到底有多简单

    已经部署好Openclaw的朋友可以直接跳过本章,看下一节内容,

    还没部署好,或者想要再白嫖优惠OpenClaw的可以看看本章。

    前两篇文章之后,大家反馈最多的问题

    关注我的朋友应该记得,前两天我连着肝了两篇 OpenClaw 的教程:

    • 第一篇是阿里云部署的,从买服务器到打通钉钉,全流程手把手
    • 第二篇更硬核,从 0 到 1 装官方原版,接了 Kimi K2.5,还搞了 Discord 远程操控

    文章发完之后,后台和群里炸了..

    大家问得最多的,基本就两类:

    一类是:"甲木,我照着你教程做,环境配置那步就卡住了,报了一堆错,咋整?"

    虽然我已经写得尽量保姆级了,但确实,

    对于没怎么碰过命令行的朋友来说,配环境、装依赖、排报错这些东西..还是劝退了不少人。

    另一类是:"教程里那些软件都是国外的,有没有更适合国内的方案?"

    嗯,这个确实是痛点。

    OpenClaw 原生适配的工具和渠道基本都是海外生态,国内想用好它,适配成本不低。

    正好,

    百度智能云这次直接上线了 OpenClaw 极简部署

    https://cloud.baidu.com/product/BCC/moltbot.html

    它同样直接提供了预装好 OpenClaw 环境的轻量应用服务器镜像。

    你在控制台选这个镜像,创建实例,几分钟就能跑起来,啥都不用手动装。

    更狠的是,它还搞了个限时免费体验首月免费,每天限量 500 台,先到先得。

    之前阿里云那个 68 块一年大家就已经觉得香了,这次百度直接搞免费...

    好家伙,卷起来了属于是。

    部署完之后,你还能直接通过千帆平台接入文心、DeepSeek、Qwen 这些模型,不用自己到处去注册账号拿 API Key。

    这对于小白来说,友好度直接拉满了。

    搭建流程,三步搞定

    第一步、买台服务器

    打开百度智能云官网(https://cloud.baidu.com/product/BCC/moltbot.html),选轻量应用服务器。

    几个关键的配置别选错:

    • 镜像:一定选 OpenClaw(Clawdbot) 应用镜像
    • 套餐:CPU 2核、内存 4GB 起步
    • 地域:按需选

    如果有优惠的话,你会看到这个界面,

    如果没优惠的话,你就只能按月付费了..

    但我给你一个思路,可以新注册一个账号...

    然后正常购买,

    踩坑提醒:OpenClaw 是 Node.js 应用,比较吃内存。2G 内存裸跑偶尔会 OOM(内存溢出),建议搞一下 Swap 交换空间,不然跑着跑着进程就没了,问我怎么知道的..

    第二步、配模型

    服务器跑起来之后,进控制台:

    等待实例创建完成后进入实例详情页,点击实例管理Tab

    1. 放通端口——防火墙那步,点一下「一键开通」就行

    这里需要注意,按量计费

    这里是直接按使用量计费的,需要注意。如果不想走千帆平台的,我们可以直接用它的服务器,然后自己搭建镜像,就跟那篇文章教大家的一样。
    1. 防火墙放通18789端口

    访问openclaw官网网站需要通过18789端口访问,点击“一键放行”放行防火墙18789端口。

    1. 接大模型——通过千帆平台配,文心、Qwen、DeepSeek 都能选

    到这里,三步其实就完事了,但千帆的好处是,选完模型之后还能顺手去 MCP 广场挑几个工具,直接给你的 OpenClaw 装上技能包

    这步体验下来确实比之前丝滑不少。

    第三步、选你的操作渠道(可选)

    可以直接在消息平台配置选择接入飞书、企业微信、钉钉、QQ

    每一个接入过程都有详细地文档,可以按需使用,然后点击应用

    比如,QQ接入,https://cloud.baidu.com/doc/LS/s/xml9eru3h

    这里不再赘述,我直接接入了QQ。

    第四步、选择skills(可选)

    接入了百度搜索、百度百科skills,这里按需选择,直接点击应用


    到这里,基本就配置完成了,你可以选择页面访问,

    也可以直接QQ对话。

    三个我实际跑通的 Skills 玩法,真的能干活那种

    平台工具说了这么多,最终还是得落地。

    百度搜索、百度百科、学术检索、智能PPT生成和AI绘本生成,这几个skills的可玩性挺多的。

    关于如何在OpenClaw中添加百度的skills,我们可以直接看https://cloud.baidu.com/doc/qianfan/s/Mmlda41a2中的内容。

    直接一句话添加,剩下的交给OpenClaw就可以了:

    下面分享三个我自己跑通的场景。

    不局限于OpenClaw,ClaudeCode、OpenClaude,都可以直接接入这几个skills,直接施展组合技。

    玩法一:热点追踪 → 一键出图文材料

    用到的 Skills:百度搜索 + 智能 PPT 生成 / AI 绘本生成

    这个场景特别适合做内容、做运营的朋友。

    我试了一下,直接给 OpenClaw 扔了一句话:

    "帮我搜一下今天 AI 领域最重要的三条新闻,然后整理成一份简报 PPT。"

    它的执行链路大概是这样的:

    1. 先调用百度搜索 Skill,从全网检索实时信息
    2. 自动筛选、去重、提取核心内容
    3. 把整理好的内容丢给智能 PPT 生成 Skill
    4. 直接输出一份带标题、分页、核心要点的 PPT

    整个过程我啥也没干,就等着收材料。

    如果你不想要 PPT 格式,换成 AI 绘本生成也行——它会把新闻内容变成图文并茂的绘本形式,特别适合发朋友圈或者做社交媒体内容。

    以前做一份热点简报,你得先翻一圈新闻网站,然后自己写摘要,再打开 PPT 模板排版..

    【插入PPT GIF图片】

    现在一句话搞定。

    这个场景还能拓展:

    • 每天早上定时跑一次,自动生成 AI 行业早报
    • 输入某个关键词,自动追踪相关热点并生成周报
    • 做竞品监控,一有动态就出分析材料

    核心逻辑就是:搜索 Skill 负责"找信息",PPT/绘本 Skill 负责"出成果",中间 Agent 负责"串起来"。

    玩法二:学术研究 Agent:会查资料、会核实、还会追问

    用到的 Skills:学术检索 + 百度百科 + 深度研究 Agent

    这个场景偏硬核一些,适合做研究、做咨询、写报告的朋友。

    普通的 AI 搜索是这样的:你问一个问题,它给你一个答案,完事了。

    但接上学术检索百度百科这两个 Skill 之后,OpenClaw 干的事就不一样了。

    我试着让它研究一个课题:AI Agent 在企业服务领域的落地现状与挑战

    它的工作方式是这样的:

    1. 拆解问题——把一个大课题拆成几个子问题

    1. 调用学术检索 Skill,去找相关的论文和研究报告

    1. 遇到不确定的概念,自动调用百度百科 Skill去核实

    1. 整理完一轮之后,它自己又追加了几个问题继续深挖

    它更像是一个真的会做研究的助手,不只是搜,还会交叉验证、会追问、会自己判断哪些信息还不够。

    百度千帆还有一个深度研究 Agentdeepresearch-conversation),专门做这种多轮拆解的研究场景。接上学术检索和百度百科之后,体验就更接近"企业研究 / 咨询分析"的工作方式了。

    如果你平时要写行业分析报告、做市场调研,或者帮老板准备决策材料,

    比如刚才的报告,我让它给我补充了一些内容。

    Deep Research Agent 基于 284 次深度搜索后...

    这个组合真的建议试试。

    玩法三:私董会 × 百度生态:让幕僚带着真数据给你出主意

    用到的 Skills:私董会 Skill + 百度搜索 + 百度百科

    这个非常有意思,skill搭配组合技。

    关注我的老朋友应该知道,之前我做过一个AI 私董会的 Skill,

    就是模拟巴菲特、比尔·盖茨、马斯克、乔布斯四位大佬当你的幕僚,通过多轮提问和反馈,帮你深入分析问题、给出可执行的建议。

    这个 Skill 之前在社区里反响很不错,很多朋友拿它来做创业决策、职业规划、项目复盘。

    但它一直有两个让我觉得不够完美的地方:

    第一,幕僚的"人设"全靠模型自己编。

    比如巴菲特这个角色,模型知道他是投资大师,但它掌握的信息可能是训练数据里的老内容。关于他最新的持仓变动、最近的股东信里说了什么、今年的投资逻辑有什么变化,模型是不知道的。

    第二,幕僚们给建议的时候,全凭"脑补"。

    聊投资策略的时候,巴菲特会引用一些经典理论和案例,但这些都是模型"记忆"里的东西。你问一个特别新、特别细的市场问题,他可能就只能泛泛而谈了。

    现在有了百度搜索和百度百科的 Skill 之后,这两个问题同时被解决了

    幕僚们不仅能"上网查资料",连自己的背景信息都能实时更新。

    什么意思呢?直接看流程图:

    这些真实信息直接注入到幕僚的人设里,他们的提问和建议就不再是"通用模板",而是带着当下真实语境的。

    然后在实际咨询环节,幕僚还能随时调用搜索去查数据来支撑自己的观点。

    我试了一下,把私董会 Skill 和百度搜索、百度百科接到同一个 OpenClaw 里。然后抛了一个问题:“我想做一个面向中小企业的 AI 培训课程,但不确定市场定位和定价策略。”

    效果还不错:

    • 巴菲特在分析定价的时候,直接调了百度搜索去查了当前市场上同类课程的价格区间,然后基于真实数据给了定价建议

    • 比尔·盖茨聊行业趋势的时候,从百度百科拉了最新的企业培训市场规模数据

    • 马斯克聊差异化竞争的时候,搜了几个海内外的竞品案例来佐证他的观点

    一句话总结:以前的私董会是"凭经验聊",现在是"带着数据聊"。

    四位幕僚的建议变得更具体、更有针对性。


    聊聊生态

    前两天刚从百度智能云的 Agent 大会回来,

    事情是这样的,百度的朋友邀请去参加这次大会,

    我去了之后发现,还有@袋鼠帝@梦飞@宇明,大型好友面基现场,

    还给整了个百度千帆开发者大使的身份..

    当然,身份不重要,重要的是我在现场发现了一些好玩的东西(如上)。

    前面三个Case其实也展示了一个更大的可能性——

    不同 Skills 之间的融合,才是 OpenClaw 真正的威力所在。

    单个 Skill 是工具,多个 Skill 组合起来就是一套完整的工作流。

    而百度千帆 MCP 广场提供了大量现成的"积木块",你只需要想清楚怎么搭就行。

    毕竟百度做搜索做了二十多年了,AI 搜索这块的积累确实是最厚的。

    而针对 Agent 的使用方式做了适配。比如学术检索 Skill 返回的结构就很适合 Agent 做后续处理。

    从选镜像到配模型到进 Web 端用,整个过程对小白太友好了。特别是部署阶段直接选 Skill 这个设计,把"跑起来"和"能干活"合成了一步,省了很多折腾。

    当然,每个云平台都有自己的优势,大家根据自己的需求选就行。

    不管云平台怎么选,我觉得这几个skills,都可以给你的🦞助手配置上,非常丝滑。

    结语

    关于OpenClaw,其实已经写了好几篇的内容了,

    今天给大家分享的百度智能云的生态,其实也给OpenClaw提供了工具,

    折腾这么多,其实就是为了让更多人能用上 OpenClaw,让它能真的解决你生活中的一些场景。

    千帆这些 Skill 生态的组合玩法,才是我觉得真正有想象空间的地方。

    后续等我把更多 Skill 组合跑通了,再给大家出详细的教程和玩法拆解。

    马上春节了,

    这周的精彩其实才刚刚开始,

    国内 AI 在这周会发力的~ 期待一波!

    以上。


    我是甲木,热衷于分享一些AI干货内容,同时也会分享AI在各行业的落地应用,我们下期再见👋🏻

    本文由mdnice多平台发布

    一、什么是跨域?

    同源策略(Same-Origin Policy)

    浏览器的同源策略是 Web 安全的基石。它规定:只有当两个 URL 的 协议(Protocol)域名(Host)端口(Port) 三者完全一致时,才被视为"同源"。

    https://app.rho.im 为基准:

    目标 URL是否同源原因
    https://app.rho.im/api/data✅ 同源协议、域名、端口均相同
    http://app.rho.im/api❌ 跨域协议不同(http vs https)
    https://api.rho.im/data❌ 跨域域名不同(子域名也算不同源)
    https://app.rho.social/page❌ 跨域域名完全不同
    https://app.rho.im:8443/api❌ 跨域端口不同(443 vs 8443)

    同源策略限制了什么?

    • XMLHttpRequest / Fetch 请求:不能读取跨域响应(最常见的场景)
    • DOM 访问:不能通过 JS 访问跨域 iframe 的 DOM
    • Cookie / LocalStorage / IndexedDB:不能读取其他源的存储数据
    注意:同源策略不阻止请求发出,而是阻止浏览器读取响应。服务器实际上收到了请求并返回了响应,只是浏览器拒绝将响应交给 JS 代码。这个细微区别非常重要。

    二、为什么需要同源策略?——安全性分析

    场景 1:防止敏感数据窃取

    假设没有同源策略:

    1. 你登录了 bank.com,浏览器存有会话 Cookie
    2. 你访问了恶意网站 evil.com
    3. evil.com 的 JS 向 bank.com/api/account 发请求(浏览器会自动带上 Cookie)
    4. 如果没有同源策略evil.com 就能读取你的银行账户信息

    这就是经典的 CSRF(跨站请求伪造) 攻击的基础。同源策略确保 evil.com 无法读取 bank.com 的响应。

    场景 2:防止 DOM 篡改

    如果允许跨域 DOM 访问:

    恶意网站嵌入 <iframe src="bank.com/login">
    → JS 读取 iframe 中用户输入的密码
    → 密码被发送到攻击者服务器

    核心安全原则

    同源策略本质上实现了一个沙箱隔离机制:每个源(origin)都在自己的沙箱里运行,无法访问其他沙箱的数据。这是最小权限原则在浏览器中的体现。


    三、常见跨域场景

    1. 前后端分离架构

    最常见的场景。前端部署在 app.rho.im,API 服务在 api.rho.im

    前端 https://app.rho.im  →  fetch("https://api.rho.im/users")  → 跨域!

    2. 单点登录(SSO)

    企业常见需求——用户登录一次即可访问多个子系统:

    认证中心: https://sso.rho.im
    应用 A:   https://app1.rho.im
    应用 B:   https://app2.rho.social

    SSO 涉及的跨域问题包括:

    • Cookie 共享sso.rho.im 设置的 Cookie,app1.rho.im 能否读取?

      • 同一父域(.rho.im)下可以通过设置 domain=.rho.im 共享
      • 不同域(.rho.im vs .rho.social)之间无法直接共享 Cookie
    • Token 传递:认证中心如何将登录状态安全地传递给各应用?
    • 跨域重定向:OAuth 流程中的 302 重定向跨越多个域

    3. 第三方服务集成

    你的网站 https://app.rho.im
      → 调用地图 API: https://api.mapbox.com
      → 嵌入支付页面: https://pay.stripe.com
      → 加载字体: https://fonts.googleapis.com

    4. 微前端架构

    不同团队的微应用部署在不同子域,需要在主应用中集成:

    主应用:     https://portal.rho.im
    微应用 A:   https://team-a.rho.im
    微应用 B:   https://team-b.rho.social

    四、跨域解决方案

    方案 1:CORS(跨域资源共享)— 最标准的方案

    服务器通过 HTTP 响应头声明"允许哪些源访问我的资源":

    Access-Control-Allow-Origin: https://app.rho.im
    Access-Control-Allow-Methods: GET, POST, PUT, DELETE
    Access-Control-Allow-Headers: Content-Type, Authorization
    Access-Control-Allow-Credentials: true

    简单请求 vs 预检请求(Preflight)

    • 简单请求:GET/POST + 常规 Header → 直接发送,浏览器检查响应头
    • 预检请求:PUT/DELETE 或自定义 Header → 浏览器先发 OPTIONS 请求询问服务器是否允许,通过后才发送实际请求
    浏览器                          服务器
      |-- OPTIONS /api/data -------->|   ← 预检请求
      |<-- 200 + CORS Headers ------|   ← 服务器回复"允许"
      |-- PUT /api/data ------------>|   ← 实际请求
      |<-- 200 + Data ---------------|

    方案 2:反向代理 — 最常用的生产方案

    通过 Nginx 等反向代理,让前端和 API 看起来在同一个源:

    server {
        server_name app.rho.im;
        
        # 前端静态资源
        location / {
            root /var/www/frontend;
        }
        
        # API 请求代理到后端服务
        location /api/ {
            proxy_pass http://backend-server:3000/;
        }
    }

    这样前端访问 https://app.rho.im/api/users 实际被代理到后端,浏览器看到的始终是同源请求。

    方案 3:JSONP — 历史遗留方案

    利用 <script> 标签不受同源策略限制的特点。仅支持 GET,已基本被 CORS 取代,了解即可。

    方案 4:postMessage — 跨窗口通信

    用于 iframe、window.open 等场景的安全跨域通信:

    // 父窗口 (https://app.rho.im) 向 iframe 发消息
    iframe.contentWindow.postMessage({ type: 'login', token: 'xxx' }, 'https://sso.rho.social');
    
    // iframe (https://sso.rho.social) 接收消息
    window.addEventListener('message', (event) => {
        if (event.origin !== 'https://app.rho.im') return; // 验证来源!
        console.log(event.data);
    });

    方案 5:Cookie 跨域策略

    策略适用场景示例
    domain=.rho.im同一父域下的子域共享sso.rho.imapp.rho.im
    SameSite=None; Secure跨站 Cookie 传递第三方登录
    Token(JWT)方案完全不同的域rho.imrho.social

    五、SSO 单点登录的跨域实现

    方案 A:共享 Cookie(同父域)

    适用于 *.rho.im 下的多个子域:

    1. 用户访问 app1.rho.im → 未登录 → 重定向到 sso.rho.im/login
    2. 用户在 sso.rho.im 登录成功
    3. sso.rho.im 设置 Cookie: Set-Cookie: token=xxx; Domain=.rho.im; Path=/
    4. 用户回到 app1.rho.im → 浏览器自动带上 Cookie → 已登录
    5. 用户访问 app2.rho.im → Cookie 同样可用 → 自动登录

    方案 B:CAS / OAuth 重定向(跨域)

    适用于 rho.imrho.social 之间:

    1. 用户访问 app.rho.social → 未登录
    2. 重定向到 sso.rho.im/authorize?redirect_uri=https://app.rho.social/callback
    3. 用户在 sso.rho.im 登录(或已登录)
    4. sso.rho.im 重定向回 app.rho.social/callback?code=AUTHORIZATION_CODE
    5. app.rho.social 后端用 code 换 token(后端到后端,不受同源策略限制)
    6. app.rho.social 设置自己域的 Cookie 或返回 JWT

    方案 C:前端 Token + postMessage

    1. 主应用打开隐藏 iframe 指向 sso.rho.im/check-session
    2. sso.rho.im 检查自己的 Cookie → 如已登录,通过 postMessage 回传 token
    3. 主应用收到 token → 存入内存 → 完成登录

    六、教学演示建议

    准备工作

    使用你的域名搭建如下环境:

    https://app.rho.im       → 前端应用(端口 8080)
    https://api.rho.im       → 后端 API(端口 3000)
    https://sso.rho.social   → SSO 认证中心

    或者本地演示:

    http://localhost:8080     → 前端
    http://localhost:3000     → API(跨端口 = 跨域)

    演示步骤

    1. 先让学员看到错误:前端直接请求跨域 API,打开 DevTools 观察报错
    2. 分析请求:在 Network 面板观察 OPTIONS 预检请求
    3. 逐步修复:添加 CORS 响应头,观察请求成功
    4. 对比方案:切换到反向代理方案,展示无需 CORS 也能工作
    5. 高级场景:演示带 Cookie 的跨域请求(credentials: 'include'
    配套的交互式演示代码

    https://gist.github.com/vistart/1ad7113fcabe411a545536795374d7d6

    在互联网安全越来越受到关注的今天,WebRTC 泄露已经成为很多人忽略但又非常危险的隐私问题。

    即便你使用了 IP工具 或代理服务器,如果浏览器的 WebRTC 功能不加以控制,你的真实 IP 仍可能被网站探测到。这就意味着所谓的“匿名浏览”可能形同虚设。本文将手把手教你如何防止 WebRTC 泄露。

    什么是 WebRTC 泄露?

    首先我们得了解,WebRTC(Web Real-Time Communication) 是一种允许浏览器直接进行音视频通话和数据传输的技术。它本身非常方便,但也有隐私隐患:

    当你打开支持 WebRTC 的浏览器访问网页时,某些 JavaScript 脚本可以绕过 IP工具 或代理,直接获取你的本地和公网 IP。

    这就叫做 WebRTC 泄露,也有人称之为 “IP 泄露”。

    泄露的 IP 可以让广告商、网站甚至黑客追踪你的真实位置。

    所以,想要安全上网,控制 WebRTC 泄露非常重要。

    如何检测自己的 IP 是否被泄露?

    在采取防护措施之前,最好先确认自己的 IP 是否真的存在泄露风险。常用方法有:

    IP泄露检测网站
    打开一些知名的 IP 泄露检测网站,可以快速判断你是否通过 IP工具 暴露了真实 IP。例如,你可以访问一些综合测试页面,看看显示的 IP 是否是你 IP工具 的 IP,还是你真实的公网 IP。

    WebRTC 泄露检测工具
    有专门的 WebRTC 泄露检测工具网站,可以模拟 WebRTC 请求,判断浏览器是否会暴露本地 IP。

    浏览器指纹检测
    值得一提的是,浏览器指纹检测 也可能揭示你的一些信息,包括浏览器版本、操作系统、屏幕分辨率等。如果配合 IP 泄露,你的匿名性就更低了。推荐使用 ToDetect指纹查询工具 来检测浏览器指纹安全情况。

    通过以上方法,你可以明确自己的隐私风险点,然后针对性防护。

    禁止 WebRTC 泄露的实用方法

    接下来,重点来了——如何在日常使用中阻止 WebRTC 泄露。这里分浏览器和插件两类方法:

    1. 浏览器内置设置

    不同浏览器对 WebRTC 的控制方式不同:

    Firefox
    打开 about:config,搜索 media.peerconnection.enabled,将其值改为 false。这样就可以彻底禁止 WebRTC 连接。

    Chrome/Edge
    默认 Chrome 没有直接开关,需要借助扩展程序来控制 WebRTC。可以通过 chrome://flags/ 查看实验性功能,但最稳妥的方法还是用插件。

    Safari
    在 Safari 的设置里,找到“WebRTC 功能”,勾选“阻止所有 WebRTC 公网 IP 地址”,即可防止 IP 泄露。

    1. 使用浏览器插件

    对于 Chrome、Edge、Firefox 等主流浏览器,使用插件是最方便的方式:

    WebRTC Leak Prevent
    可以直接阻止 WebRTC 访问本地和公网 IP,同时提供 IP工具 兼容模式。

    uBlock Origin
    虽然主要用于广告拦截,但高级设置里可以控制 WebRTC 请求。

    ScriptSafe / NoScript
    可以通过屏蔽不信任的 JavaScript,间接防止 WebRTC 泄露。

    这些插件在安装后几乎可以做到“开箱即用”,降低被追踪的风险。

    其他提升隐私安全的技巧

    除了禁止 WebRTC 泄露,还有一些小技巧可以提升浏览器的隐私保护能力:

    定期检测 IP 泄露
    每隔一段时间使用 IP泄露检测 或 WebRTC 泄露检测 工具,确保 IP工具 没有被绕过。

    使用隐身模式或专门的隐私浏览器
    像 Tor Browser 或 Brave,都有更强的防止 浏览器指纹检测 和 IP 泄露的功能。

    关注浏览器更新和安全补丁
    有些漏洞会被利用来绕过 WebRTC 限制,保持浏览器最新是最基本的防护。

    结合 ToDetect 指纹查询工具
    通过 ToDetect指纹查询工具,你可以看到自己浏览器的指纹信息是否容易被追踪,进一步优化隐私设置。

    总结

    WebRTC 泄露 可能看起来小问题,但一旦被追踪,你的匿名性和隐私都会受到影响。实用的方法就是:

    定期做 IP泄露检测 和 WebRTC 泄露检测。

    根据浏览器类型,关闭或限制 WebRTC 功能。

    使用可靠的隐私插件,比如 WebRTC Leak Prevent。

    检测浏览器指纹,利用 ToDetect指纹查询工具 做进一步优化。

    只要按照这些步骤操作,你就能大幅降低 IP泄露 风险,保护自己在网络世界的隐私安全。

    做 ArkTS / ArkUI 时,把“运行-看效果”的成本降下来,最省事的方式之一就是用 DevEco 的预览器(Previewer)。它能让你在不装包、不跑真机的情况下,快速验证 UI 结构、布局、样式与适配问题。

    组件预览的核心价值不是“看一眼 UI”,而是把预览变成一种工作流:每写一个组件,就配一组稳定可复用的预览场景,后续调样式、做适配、做重构,都能快速回归验证。


    1)先搞清:页面预览 vs 组件预览(别混用)

    很多同学一开始会把这两种预览混在一起用,导致预览行为“看起来不对”。

    • 页面预览:以“页面”为单位,通常在页面组件上加 @Entry,适合看整体页面结构与导航。
    • 组件预览:以“自定义组件”为最小单位,靠 @Preview 装饰器触发,更适合做组件库、模块化 UI、局部迭代调试。

    你如果正在做组件化(卡片、列表项、通用按钮、弹窗、空状态等),优先用组件预览,效率更高。


    2)环境准备清单(预览器能不能跑,先看这几项)

    如果预览器打不开、白屏、显示异常,先按这几条排:

    1. 显卡/图形能力要满足预览器要求:有些机器 OpenGL 能力不够时,预览器会异常或非常卡。
    2. DevEco 的 Previewer 资源要下载完整:SDK、预览器组件没装齐,经常会出现“能编译但无法预览”。
    3. 部分组件或能力天然不适合预览:例如 Web、Video、XComponent 等更依赖运行态环境的组件,预览里容易出现空白或异常。

    3)@Preview 最小可用写法:先跑通“无参组件”

    建议你先用一个不依赖外部参数、状态可控的组件验证预览链路,确保预览器能正常工作:

    @Preview
    @Component
    struct HelloPreview {
      @State message: string = 'default Preview';
    
      build() {
        Column() {
          Text(this.message).fontSize(40).fontWeight(FontWeight.Bold)
        }
        .width('100%')
        .height('100%')
      }
    }

    小提醒:别在一个文件里堆太多预览

    一个源文件里预览太多,会让维护成本上升,也容易让预览器负担变大。建议一个文件控制在“够用就好”。


    4)PreviewParams:把预览“调成你想要的设备/语言/方向”

    当你开始做多端适配或国际化时,@Preview({...}) 的参数就特别有用。你可以把预览设备的关键属性固定下来,比如屏幕大小、语言、方向、圆屏等。

    常用参数解释(按实际开发最常用的理解方式):

    • title:预览名称,同文件多个预览时用来区分。
    • width / height:预览设备分辨率(px),快速模拟不同屏幕尺寸。
    • dpi:屏幕密度,用于验证字体/间距在不同密度下的表现。
    • locale:语言地区,如 zh_CNen_US,用于验证国际化布局溢出。
    • colorMode:亮暗模式(注意不同设备类型可能有默认限制)。
    • deviceType:设备类型,如 Phone/Tablet/TV/Wearable,用于多端渲染差异验证。
    • orientation:横竖屏,portraitlandscape
    • roundScreen:是否圆屏,用于手表类布局验证。

    示例(传参预览):

    @Preview({
      title: 'PreviewParams',
      width: 540,
      height: 1170,
      locale: 'zh_CN',
      orientation: 'portrait'
    })
    @Component
    struct Test {
      @State message: string = 'PreviewParams';
    
      build() {
        Column() {
          Text(this.message).fontSize(36).fontWeight(FontWeight.Bold)
        }
        .width('100%')
        .height('100%')
      }
    }

    5)实战建议:把预览做成“3 套固定组合”,效率会高很多

    我更建议你别每次临时改参数,而是固定三套预览,当成组件的“标准工位”:

    1. Phone 竖屏 + 中文
      主战场:布局、字号、间距先在这里定。
    2. Phone 横屏 + 英文
      很容易暴露英文文案溢出、按钮变形、间距不够等问题。
    3. 圆屏或小尺寸设备
      专门抓边距、圆角、安全区、内容被裁切的问题。

    当你把这三套组合固定下来,后面组件改版基本就是“一眼能看出问题”。


    6)“预览不显示/白屏”排查口诀(社区里最常见)

    遇到预览器不显示,按这个顺序排,命中率很高:

    1. 先确认是不是用了不适合预览的组件
      先临时注释 Web/Video/XComponent 等组件,验证是不是它们导致的空白。
    2. 组件是否依赖运行态数据
      例如必须等网络请求、路由参数、注入对象才能渲染。预览模式下经常会卡住或无内容。
      更稳的做法是:用“预览包装组件”把入参写死,让预览组件能独立渲染。
    3. 资源加载是否写得太“运行态”
      比如路径、资源引用方式不规范,导致预览场景拿不到资源。
    4. SDK / 预览器资源 / 项目配置是否一致
      预览器资源没下载好、SDK 版本不匹配,都会导致预览异常。

    把 @Preview 当成“组件单测”,你会越写越快

    组件预览最爽的一点是:它能把“改一点 → 看一下 → 再改一点”的循环速度拉到极致。

    当你开始把预览当成固定资产(多端、语言、方向、圆屏都覆盖),你写组件会越来越像做“可回归的模块开发”:
    改动可控、验证快速、适配心里有底。