文本转语音（TTS）领域又迎来一位重磅新星！

由 Nari Labs 开发的 Dia-1.6B 以其超逼真的对话生成能力引发热议，仅开源两天便在 GitHub 收获 6.5K+ Star！

据说其能力超越了 ElevenLabs 和 Sesame，仅凭借 1.6B 参数就可实现情感控制、非语言声音（如笑声、咳嗽）和零样本声纹克隆，运行效率惊人。

支持从文本脚本生成多角色对话，通过 [S1]、[S2] 标签区分角色，生成自然语音，并支持非语言表达和声纹克隆，目前仅限英语。

它在 Hugging Face 也提供了模型权重和 Gradio Demo 体验。

主要功能

• 多角色对话生成：使用 [S1]、[S2] 等标签区分角色，单次生成多角色对话，保持自然节奏和情感过渡。


• 拟人化表达：支持笑声(laugh)、叹气(sigh）、咳嗽(cough)等非语言情绪


• 零样本声纹克隆：可微调或指定语音风格，克隆用户或角色声音


• 高质量语音合成：音质媲美 ElevenLabs、Sesame，细节自然，情绪变化真实


• 实时推理速度：A4000 显卡上约 40 tokens/s，体验流畅无等待


• Gradio 界面支持：自带可用的 Web UI 界面，输入文本立即试听

快速上手

Dia-1.6B 官方实验室提供了详细安装指南和 Gradio 演示。

在线体验：

无需配置环境，打开 Hugging Face Demo 即可输入脚本或音频试听效果：

Demo：huggingface.co/spaces/nari…

安装部署与使用步骤：

1、克隆项目

git clone https://github.com/nari-labs/dia.git

cd dia

2、创建虚拟环境

python -m venv .venv

source .venv/bin/activate

3、安装依赖

pip install -e .

4、启动 Gradio UI

python app.py

访问 http://localhost:7860，输入脚本或上传音频，生成对话。

示例脚本：

[S1] Dia is amazing! [S2] Yeah, it generates laughs too! (laughs)

还可以通过 Python 包安装 Dia 的API

# Install directly from GitHub

pip install git+https://github.com/nari-labs/dia.git

Python 调用示例：

import soundfile as sf



from dia.model import Dia





model = Dia.from_pretrained("nari-labs/Dia-1.6B")



text = "[S1] Dia is an open weights text to dialogue model. [S2] You get full control over scripts and voices. [S1] Wow. Amazing. (laughs) [S2] Try it now on Git hub or Hugging Face."



output = model.generate(text)



sf.write("simple.mp3", output, 44100)

后续也将推出 pypi包和CLI工具。

使用场景推荐

• 有声读物 / 小说播报：让不同角色“开口说话”，配合情绪词还原真实语境


• 播客配音：快速合成带感情、有风格的访谈类语音


• AI 角色扮演：配合 Agent，多角色模拟对话系统


• TTS 研究与微调：声音克隆、情绪控制、非语言表达

写在最后

Dia-1.6B 是开源 TTS 领域的最新研究成果，其逼真对话和低资源需求让人惊叹。

小体量（1.6B 参数）却能生成媲美 ElevenLabs、Sesame 的高保真语音，甚至能区分角色、模拟非语言情绪（比如：[咳嗽]、[叹气]、[笑声]）。

其免费开源 + 超高拟真度 + 多角色/非语言表达全支持，使其成为目前开源TTS领域最值得关注的TTS项目之一！

不过目前仅支持英文，期待后续能够支持中文及更多语言。

GitHub 项目地址：github.com/nari-labs/d…

HF 模型地址：huggingface.co/nari-labs/D…

在线Demo：huggingface.co/spaces/nari…

如果你有个 AI 角色，想让它“开口说话”，甚至“笑一下”，Dia-1.6B 那就太适合了。

最近项目中在实现一个搜索的功能，根据 Flutter 的类似组件的调用习惯，输入 showSearch 后发现还真有，跳进源码中一看，Flutter 已经实现了相应的 Widget 和交互，简直不要太方便了，先来看看如何调用的。

showSearch 方法介绍

Future<T?> showSearch<T>({

  required BuildContext context,

  required SearchDelegate<T> delegate,

  String? query = '',

  bool useRootNavigator = false,

}) {

  assert(delegate != null);

  assert(context != null);

  assert(useRootNavigator != null);

  delegate.query = query ?? delegate.query;

  delegate._currentBody = _SearchBody.suggestions;

  return Navigator.of(context, rootNavigator: useRootNavigator).push(_SearchPageRoute<T>(

    delegate: delegate,

  ));

}

上面函数定义在源码 flutter/lib/src/material/search.dart 文件中，根据该函数要求须传入一个 context 和 delegate，context 是我们的老朋友，这里就无需过多介绍了。但是这个 delegate (SearchDelegate 类)是干啥的？继续跳到 SearchDelegate 发现SearchDelegate 是一个抽象类，SearchDelegate 第一句介绍 Delegate for [showSearch] to define the content of the search page. 定义搜索页面的内容，也就是说需要我们创建一个继承自 SearchDelegate 的子类来实例化参数 delegate，下面是这个子类CustomSearchPageDelegate的代码。

class CustomSearchPageDelegate extends SearchDelegate<String> {

  // 搜索框右边的显示，如返回按钮

  @override

  List<Widget>? buildActions(BuildContext context) {}



  // 搜索框左边的显示，如搜索按钮

  @override

  Widget? buildLeading(BuildContext context) {}



  // 搜索的结果展示，如列表 ListView

  @override

  Widget buildResults(BuildContext context) {}



  // 输入框输入内容时给出的提示

  @override

  Widget buildSuggestions(BuildContext context) {}

}

从上面可以看出我们需要返回4个 Widget 来显示内容，其中 buildLeading 和 buildActions 分别对应搜索框左右两边的内容，通常是 button，如 buildLeading 是返回按钮，buildActions 右边是搜索按钮。buildResults 则表示搜索的结果展示，通常是一个列表，而 buildSuggestions 展示当用户在输入框输入内容时给出的提示，展示多条提示内容时也会用到列表（ListView）。

实现 CustomSearchPageDelegate

接下来以搜索文章为例子利用自定义的CustomSearchPageDelegate 类实现一下搜索功能。

import 'package:flutter/material.dart';

import 'package:flutter_svg/flutter_svg.dart';

import 'package:flutter_todo/pages/search_page/data_item_model.dart';

import 'package:flutter_todo/pages/search_page/search_item_widget.dart';



class CustomSearchPageDelegate extends SearchDelegate<DataItemModel> {

  CustomSearchPageDelegate({

    String? hintText,

    required this.models,

  }) : super(

          searchFieldLabel: hintText,

          keyboardType: TextInputType.text,

          textInputAction: TextInputAction.search,

        );



  /// 搜素提示

  List<String> suggestions = [

    "Flutter",

    "Flutter开发7个建议，让你的工作效率飙升",

    "浅谈 Flutter 的并发和 isolates",

    "Flutter 技术实践",

    "Flutter 中如何优雅地使用弹框",

    "Flutter设计模式全面解析：单例模式",

    "Flutter Dart",

    "Flutter 状态管理",

    "Flutter大型项目架构：UI设计系统实现（二）",

    "Flutter大型项目架构：分层设计篇",

    "Dart 语法原来这么好玩儿"

  ];



  /// 模拟数据，一般调用接口返回的数据

  List<DataItemModel> models = [];



  /// 搜索结果

  List<DataItemModel> results = [];



  /// 右边的搜索按钮

  @override

  List<Widget>? buildActions(BuildContext context) {

    return [

      InkWell(

        onTap: () {},

        child: Container(

          margin: const EdgeInsets.all(10),

          height: 30,

          alignment: Alignment.center,

          decoration: BoxDecoration(

              color: Colors.red, borderRadius: BorderRadius.circular(30)),

          padding: const EdgeInsets.symmetric(vertical: 0, horizontal: 16),

          child: const Text(

            "搜索",

            style: TextStyle(color: Colors.white, fontSize: 14),

          ),

        ),

      ),

    ];

  }



  /// 左边返回按钮

  @override

  Widget? buildLeading(BuildContext context) {

    return InkWell(

        onTap: () {

          /// 返回操作，关闭搜索功能

          /// 这里应该返回 null

          close(context, DataItemModel());

        },

        child: Container(

          padding: const EdgeInsets.all(15.0),

          child: SvgPicture.asset(

            "assets/images/arrow.svg",

            height: 22,

            color: Colors.black,

          ),

        ));

  }



  /// 搜索结果列表

  @override

  Widget buildResults(BuildContext context) {

    return ListView.separated(

      physics: const BouncingScrollPhysics(),

      itemCount: results.length,

      itemBuilder: (context, index) {

        DataItemModel item = results[index];

        /// 自定义Widget，用来显示每一条搜素到的数据。

        return SearchResultItemWidget(

          itemModel: item,

          click: () {

            /// 点击一条数据后关闭搜索功能，返回该条数据。

            close(context, item);

          },

        );

      },

      separatorBuilder: (BuildContext context, int index) {

        return divider;

      },

    );

  }



  /// 提示词列表

  @override

  Widget buildSuggestions(BuildContext context) {

    List<String> suggestionList = query.isEmpty

        ? []

        : suggestions

            .where((p) => p.toLowerCase().contains(query.toLowerCase()))

            .toList();

    if (suggestionList.isEmpty) return Container();

    return ListView.separated(

      itemBuilder: (context, index) {

        String name = suggestionList[index];

        return InkWell(

          onTap: () {

            /// 点击提示词，会根据提示词开始搜索，这里模拟从models数组中搜索数据。

            query = name;

            results = models

                .where((e) =>

                    (e.title?.toLowerCase().contains(name.toLowerCase()) ??

                        false) ||

                    (e.desc?.toLowerCase().contains(name.toLowerCase()) ??

                        false))

                .toList();



            /// 展示结果，这个时候就调用 buildResults，主页面就会用来显示搜索结果

            showResults(context);

          },

          child: Container(

            color: Colors.white,

            padding: const EdgeInsets.symmetric(vertical: 15, horizontal: 10),

            child: Row(

              children: [

                SvgPicture.asset(

                  "assets/images/search.svg",

                  height: 16,

                  color: const Color(0xFF373737),

                ),

                const SizedBox(

                  width: 4,

                ),

                RichText(

                  text: TextSpan(children: getSpans(name)),

                ),

              ],

            ),

          ),

        );

      },

      itemCount: suggestionList.length,

      separatorBuilder: (BuildContext context, int index) {

        return divider;

      },

    );

  }



  /// 分割线

  Widget get divider => Container(

        color: const Color(0xFFAFAFAF),

        height: 0.3,

      );



  /// 富文本提示词，其中如果和输入的文本匹配到的关键字显示红色。

  List<TextSpan> getSpans(String name) {

    int start = name.toLowerCase().indexOf(query.toLowerCase());

    String end = name.substring(start, start + query.length);

    List<String> spanStrings = name

        .toLowerCase()

        .replaceAll(end.toLowerCase(), "*${end.toLowerCase()}*")

        .split("*");

    return spanStrings

        .map((e) => (e.toLowerCase() == end.toLowerCase()

            ? TextSpan(

                text: e,

                style: const TextStyle(color: Colors.red, fontSize: 14))

            : TextSpan(

                text: e,

                style:

                    const TextStyle(color: Color(0xFF373737), fontSize: 14))))

        .toList();

  }

}

这里要说明一下，query 关键字是输入框的文本内容。调用的时候实例化一下该类，传递给 shwoSearch 的 delegate 参数。下图就是我们看到的效果：

总结问题

以上图片的搜索框还可以通过重写 appBarTheme 来定制自己想要的 UI 效果，虽然可以这样，但是和我们要实现的效果比起来还相差甚远，尤其是顶部的搜索框，其左右两边的留白区域过多，背景颜色无法调整，内部的输入框 TextField 也无法定制自己想要的效果，如不能调整其圆角、背景颜色以及添加额外控件等等。

还有一点就是当我们点击返回按钮调用 close 时，这里返回值是泛型 T 却不支持 null 类型，在文章的开头，我们可以看到 shwoSearch 的 delegate 参数类型是 SearchDelegate<T>，所以创建 CustomSearchPageDelegate 时必须这样去声明。

class CustomSearchPageDelegate extends SearchDelegate<DataItemModel>

而我们想要实现这样去声明

class CustomSearchPageDelegate extends SearchDelegate<DataItemModel?>

这样当我们调用 close 时可以做到传 null，在外面调用的位置可以对返回值进行判断，返回值为 null 就不作任何处理。

交互上，在点击键盘上的 搜索 按键时，直接调用的是 showResults 函数，而通常的操作是需要调用搜索的接口拿到数据后，再去调用 showResults 函数来展示搜索结果的数据。

对于上述问题，我们可以做什么呢？

源码分析

想要到达我们需要的效果，还是需要看看 Flutter 的源码是怎么实现的，我们再次来到 flutter/lib/src/material/search.dart 文件中，可以看到该文件中定义了除上面提到的抽象类 SearchDelegate 和全局函数 showSearch 之外，还有内部类 _SearchPageRoute 和 _SearchPage。 _SearchPageRoute 继承自 PageRoute，顾名思义就是负责路由跳转及转场动画的。

以下是 _SearchPageRoute 部分代码：

class _SearchPageRoute<T> extends PageRoute<T> {

  _SearchPageRoute({

    required this.delegate,

  }) : assert(delegate != null) {

    delegate._route = this;

  }



  final SearchDelegate<T> delegate;

  

  /// ...

  

  @override

  Widget buildPage(

    BuildContext context,

    Animation<double> animation,

    Animation<double> secondaryAnimation,

  ) {

    return _SearchPage<T>(

      delegate: delegate,

      animation: animation,

    );

  }

  

  /// ...

}

重写父类的 buildPage 方法，将 delegate 传递给 _SearchPage 并将其返回，而所有的 UI 逻辑都在这个 _SearchPage 中，来到 _SearchPage 的 build 函数中就可以看到下面的实现。

_SearchPage 的 build 函数代码

@override

Widget build(BuildContext context) {

  assert(debugCheckHasMaterialLocalizations(context));

  final ThemeData theme = widget.delegate.appBarTheme(context);

  final String searchFieldLabel = widget.delegate.searchFieldLabel

    ?? MaterialLocalizations.of(context).searchFieldLabel;

  Widget? body;

  // _currentBody 枚举类型_SearchBody，用来区分当前body是展示提示列表还是搜索结果列表，

  // 当调用 SearchDelegate 中 showResults 函数时，_currentBody = _SearchBody.results

  // 当调用 SearchDelegate 中 showSuggestions 函数时，_currentBody = _SearchBody.suggestions

  switch(widget.delegate._currentBody) {

    case _SearchBody.suggestions:

      body = KeyedSubtree(

        key: const ValueKey<_SearchBody>(_SearchBody.suggestions),

        child: widget.delegate.buildSuggestions(context),

      );

      break;

    case _SearchBody.results:

      body = KeyedSubtree(

        key: const ValueKey<_SearchBody>(_SearchBody.results),

        child: widget.delegate.buildResults(context),

      );

      break;

    case null:

      break;

  }



  return Semantics(

    explicitChildNodes: true,

    scopesRoute: true,

    namesRoute: true,

    label: routeName,

    child: Theme(

      data: theme,

      child: Scaffold(

        appBar: AppBar(

          leading: widget.delegate.buildLeading(context),

          title: TextField(

            controller: widget.delegate._queryTextController,

            focusNode: focusNode,

            style: widget.delegate.searchFieldStyle ?? theme.textTheme.titleLarge,

            textInputAction: widget.delegate.textInputAction,

            keyboardType: widget.delegate.keyboardType,

            onSubmitted: (String _) {

              widget.delegate.showResults(context);

            },

            decoration: InputDecoration(hintText: searchFieldLabel),

          ),

          actions: widget.delegate.buildActions(context),

          bottom: widget.delegate.buildBottom(context),

        ),

        body: AnimatedSwitcher(

          duration: const Duration(milliseconds: 300),

          child: body,

        ),

      ),

    ),

  );

}

_SearchPage 中的实现也非常简单，就是一个嵌入到 AppBar 中的搜索框和呈现 suggestion list 及 result list 的 body。想要定制自己的 UI 效果，改的也是该位置的代码。

优化实现

UI 方面主要针对 TextField 和 AppBar 代码修改，怎么改就看想要实现什么效果了。参考 Flutter 官方的源码，重新实现一个的 _SearchPage 类，然后在 _SearchPageRoute 替换成自己写的 _SearchPage，再去 SearchDelegate 替换一下修改过的 _SearchPageRoute。

还一个问题怎么实现调用 close 时可以返回 null 的结果内呢？除了上面提到的这样去声明

class CustomSearchPageDelegate extends SearchDelegate<DataItemModel?>

之外，还需要修改 _SearchPageRoute 。

// 改之后

final CustomSearchDelegate<T?> delegate;

// 改之前

// final CustomSearchDelegate<T> delegate;

重新定义一个全局函数 showSearchWithCustomiseSearchDelegate，和官方的区分开来。

Future<T?> showSearchWithCustomiseSearchDelegate<T>({

  required BuildContext context,

  // 这里的泛型由原来的 T 改成了 T?

  required CustomSearchDelegate<T?> delegate,

  String? query = '',

  bool useRootNavigator = false,

}) {

  delegate.query = query ?? delegate.query;

  delegate._currentBody = _SearchBody.suggestions;

  // 这里的 _SearchPageRoute 是我们自己实现的类

  return Navigator.of(context, rootNavigator: useRootNavigator)

      .push(_SearchPageRoute<T>(

    delegate: delegate,

  ));

}

来看看最终调用上面的函数

DataItemModel? result =

    await showSearchWithCustomiseSearchDelegate(

        context: context,

        delegate: SearchPageDelegate(

            hintText: "Flutter 技术实践", models: models));

if (result != null) {

  /// to detail page

}

解决交互上的问题，需要在我们自己抽象类 SearchDelegate 单独定义一个函数 onSubmit，点击键盘上的搜索按键和右边的搜索按钮调用 onSubmit 函数，如：widget.delegate.onSubmit(context, text);，在 SearchDelegate 子类的 onSubmit 中来实现具体的逻辑，如发送网络请求，返回数据后在调用 showResults。

@override

void onSubmit(BuildContext context, String text) {

  // 发送网络请求，拿到数据。

  // showResults(context);

}

整体实现的代码量多，就不在文中贴出来了，具体实现大家可以参考这里的代码：
github.com/joedrm/flut…

下图是最终实现效果：

小结

自定义搜索框的实现整体来说还是比较简单的，相比于源码改动的地方并不多，就可以显示想要的效果。当然还有其它更多的实现方式，这里只是提供了一种分析思路。我们还可以发散一下，去看看其它的如：showBottomSheet、showDialog 等等和 SearchDelegate，他们直之间也有不少类似的地方，当我想要自定义自己的控件时，会发现其实很多答案就在官方的源码里，动手改吧改吧就出来了。最后聊一下近况，近期有一些想法在忙着实现，时间有点安排不过来，文章的更新就有点儿偷懒了，跟大家说声抱歉，后面有机会单独来分享一下最近忙的事情，最后感谢大家耐心的阅读！

短信，从曾经的日常对话，变成了今天只在收验证码、收通知时才偶尔想起的工具。我们不再用它聊天，但它却以另一种方式，继续默默留在了每一部手机里——像一条永不熄灭的应急通道，安静又顽强。

为什么传统短信衰落了？

我想，原因显而易见：

• 体验落后：纯文本，沉闷乏味，与今天充满表情包、短视频的社交体验格格不入。


• 安全问题：垃圾信息与钓鱼链接充斥，带来隐私泄露和金融诈骗风险。


• 替代者崛起：OTT应用（如微信等即时通讯）越过运营商，构建了更强大且丰富的通讯体验。

一句话总结：自第一代iPhone发布以来，短信从未进化过。

但近两年，5G消息的概念强势崛起：试图“复活”短信。

它被认为是短信的升级版，是一种长得更好看的短信，支持文本、图片、音频、视频、定位、支付、卡片应用等丰富媒介内容，如图。它试图成为新的“杀手级应用”，补齐传统短信缺失的智能与体验。

但问题来了 —— 对用户来说，这些体验在APP应用里早已稀松平常，“了无新意”。。。5G消息远远谈不上颠覆，只是跟上了过去的潮流。

思考

这里想问大家一句：短信最大的优势是什么？

—— 我认为可能是有一点：那就是 “强推送“ 。即只要拿到了手机号，不管你愿意不愿意，就能给你发短信！

—— 这个可以是正向积极的、比如，如果在地震台风来临时，谁也不想错过“被强推送”一条预警消息。或者：你订阅了关注金价走势的服务，每天早上9点，直接推送一条金价信息，也不会让人太反感尔尔。

—— 也可以是负面消极的，比如消息轰炸、低劣推销、骚扰信息的等。

本瓜认为：真正的变化不应该是“形式”，应该发生在基础设施层。

现在的消息生态，并不是单一平台控制的，而是：运营商、手机厂商、MaaP平台、AI服务商、HUB厂商、SDK厂商、企业用户等多方共建。

多方参与虽然打破了垄断，但也带来了潜在的协调低效与体验分裂问题。

移动互联网的成功经验告诉我们：轻应用，才是黏住用户、构建生态的核心。

1、对用户而言：免安装、免更新、即用即走、无缝切换。—— 是好的！

2、对开发者而言：开发简单、成本低、快速迭代。—— 也是好的！

在App平台上，代表性的轻应用是小程序。而在5G消息体系里，对应的是Chatbot（聊天机器人） 。—— 就有点像把如今火爆的智能体加入到短信里。

虽然聊天机器人前端看似简单，但背后隐藏着巨大的开发挑战：不仅是UI，而是要设计对话剧本、逻辑分支；还有自然语言输入不确定，需要NLP、NLU技术精准理解；需要训练、调优，否则容易出错让用户失望等等。

对企业来说，想开发一个成熟Chatbot的难度和投入，远超表面。所以，这也是为什么现在你还没有开始在短信界面呼起各类机器人/应用。

未来企业很可能同时包含：

• App：重应用，沉淀核心用户。


• 小程序：轻应用，覆盖广泛场景。


• Chatbot：对话应用，增强即时服务与主动触达能力：智能客服、营销互动

问题又来了： 要支撑这样分散、灵活、快速演化的格局，需要怎样的基础设施？

可能需要一套完善的 沙箱计划：即允许应用以轻量方式接入、运行、管理，同时保障数据隔离、安全合规。

引言

最近产品经理看到抖音的个人主页下拉效果很不错，让我也实现一个，如果是native还好办，开源成熟的库一大堆，可我是Flutter呐🤣，业内成熟可用的库非常有限，最终跟产品经理batte失败后，没办法只能参考native代码硬肝出来。

效果图

整体构思

实现拖拽滑动功能，关键在于对手势事件的识别。在 Flutter 中，可使用Listener来监听触摸事件，如下所示：

Listener(

  onPointerDown: (result) {

   

  },

  onPointerMove: (result) {

   

  },

  onPointerUp: (_) {

  

  }

在手指滑动的过程中不断的刷新背景图高度是不是就可以实现图片的拉伸效果呢？我们这里图片加载库使用CachedNetworkImage，高度在156的基础上动态识别手指的滑动距离extraPicHeight

CachedNetworkImage(

  width: double.infinity,

  height: 156 + extraPicHeight,

  imageUrl: backgroundUrl,

  fit: fitType,

)

识别到手指滑动就不断的刷新拉伸高度extraPicHeight，flutter setState 内部已经做了优化，不用担心性能问题，实际效果体验很不错。

setState(() {

 extraPicHeight；

});

经过实验思路是没有问题，那么监听哪些事件，extraPicHeight到底怎么计算，有什么边界值还考虑到呢？我们从手势的顺序开始梳理一下。

首先按压屏幕会识别到触碰屏幕起点，也就是initialDx initialDy，对于下拉拖拽我们关心更多的是纵向坐标result.position.dy

onPointerDown: (result) {

  initialDy = result.position.dy;

  initialDx = result.position.dx;

},

当手指在屏幕滑动会触发onPointerMovew,result.position.dy代表的就是手势滑动的位置

onPointerMove: (result) {

  //手指的移动时

  // updatePicHeight(result.position.dy); //自定义方法，图片的放大由它完成。

},

这边处理逻辑比较复杂，我们先抽成函数updatePicHeight

updatePicHeight(changed) {

  //。。。已省略不重要细节代码

  extraPicHeight += changed - prev_dy; //新的一个y值减去前一次的y值然后累加，作为加载到图片上的高度。

  debugPrint('extraPicHeight updatePicHeight : $extraPicHeight');

  //这里是为了限制我们的最大拉伸效果

  if (extraPicHeight > 300) {

    extraPicHeight = 300;

  }

  if (extraPicHeight > 0) {

    setState(() {

      prev_dy = changed;

    });

  }

}

这里简化了很多细节逻辑，核心目的就是要不断的累加我们的拖动距离来计算extraPicHeight高度，这里的changed是我们手指的y坐标，滑动的距离需要减去上次滑动的回调y,所以我们必须声明一个过去y坐标的变量也就是prev_dy，通过通过 changed - prev_dy就可以得出真正滑动的距离，然后我们不断累加 extraPicHeight += changed - prev_dy就是图片的拉伸距离。

手指下拉以后图片确实拉伸了，但是松开手后发现回不去了🤣因为我们还需要处理图回去的问题，既然可以通过setState把图片高度拉高，我们也可以通过setState把图片高度刷回去，核心要思考的是如何平滑的让图片自己缩回去呢？有经验的你一定想到动画了。

flutter这里的动画库是Tween，Tween可以通过addListener监听距离的回调，当距离变化不断刷新图片高度

anim = Tween(begin: extraPicHeight, end: 0.0).animate(animationController)

  ..addListener(() {

    setState(() {

      extraPicHeight = anim.value;

      fitType = BoxFit.cover;

    });

  });

prev_dy = 0; //同样归零

动画的效果最终由控制器animationController来决定，这里给了一个300ms的时间还不错，可以根据自己业务扩展

animationController = AnimationController(

    vsync: this, duration: const Duration(milliseconds: 300));

所有在手抬起的时候执行我们的动画runAnimate函数即可

onPointerUp: (_) {

  //当手指抬起离开屏幕时

  if (isVerticalMove) {

    if (extraPicHeight < 0) {

      extraPicHeight = 0;

      prev_dy = 0;

      return;

    }

    debugPrint('extraPicHeight onPointerUp : $extraPicHeight');

    runAnimate(); //动画执行

    animationController.forward(from: 0); //重置动画

  }

},

整体的技术方案履完了，之后就是细节问题了

问题1:横行稍微有倾角的滑动也会导致页面拖拽，比如侧滑返回上一页面

这是由于手指滑动的角度没有限制， 这里我们计算一下滑动倾角，超过45度无效，角度计算通过x,y坐标计算tan函数即可

onPointerMove: (result) {

  double deltaY = result.position.dy - initialDy;

  double deltaX = result.position.dx - initialDx;

  double angle =

      (deltaY == 0) ? 90 : atan(deltaX.abs() / deltaY.abs()) * 180 / pi;

  debugPrint('onPointerMove angle : $angle');

  if (angle < 45) {

    isVerticalMove = true; // It's a valid vertical movement

    updatePicHeight(result

        .position.dy); // Custom method to handle vertical movement

  } else {

    isVerticalMove =

        false; // It's not a valid vertical movement, ignore it

  }

}

问题2:图片高度变了，为啥没有拉伸啊！

图片拉伸取决于你图片库的加载配置，以flutter举例，我们的图片库是CachedNetworkImage

 CachedNetworkImage(

  width: double.infinity,

  height: 156 + extraPicHeight,

  imageUrl: backgroundUrl,

  fit: fitType,

)

加载效果取决于fit，默认不变形我们使用cover，拉伸时使用fitHeight或者fill

updatePicHeight(changed) {

  if (prev_dy == 0) {

    //如果是手指第一次点下时，我们不希望图片大小就直接发生变化，所以进行一个判定。

    prev_dy = changed;

  }

  if (extraPicHeight > 0) {

    //当我们加载到图片上的高度大于某个值的时候，改变图片的填充方式，让它由以宽度填充变为以高度填充，从而实现了图片视角上的放大。

    fitType = BoxFit.fitHeight;

  } else {

    fitType = BoxFit.cover;

  }

  extraPicHeight += changed - prev_dy; //新的一个y值减去前一次的y值然后累加，作为加载到图片上的高度。

  debugPrint('extraPicHeight updatePicHeight : $extraPicHeight');

  if (extraPicHeight > 300) {

    extraPicHeight = 300;

  }

  if (extraPicHeight > 0) {

    setState(() {

      prev_dy = changed;

      fitType = fitType;

    });

  }

}

最后看下组件如何布局

 CustomScrollView(

      physics: const NeverScrollableScrollPhysics(),

      slivers: <Widget>[

        SliverToBoxAdapter(

          child: buildTopWidget(),

        ),

        SliverToBoxAdapter(

          child: Column(

            children: contents,

          ),

        )

      ]

      ),

)

整个列表使用CustomScrollView，因为在flutter上用他才能实现这种变化效果，未来还可以扩展顶部导航栏的变化需求。buildTopWidget就是我们头部组件，包括内部的背景图，但是整个组件和背景图的高度都是依赖extraPicHeight变化的，contents是我们的内容，当头部组件挤压，会正常跟随滑动到底部。

全局变量依赖以下参数就够了，核心要注意的就是边界值问题，什么时候把状态值重置问题。

//初始坐标

double initialDy = 0;

double initialDx = 0;

double extraPicHeight = 0; //初始化要加载到图片上的高度

late double prev_dy; //前一次滑动y

//是否是垂直滑动

bool isVerticalMove = false;

//动画器

late AnimationController animationController;

late Animation<double> anim;

技术语言不是我分享的核心，解决这个需求的技术思维路线是我们大家可以借鉴学习的。

如果你有任何疑问可以通过掘金联系我，如果文章对你有所启发，希望能得到你的点赞、关注和收藏，这是我持续写作的最大动力。Thanks~

随着互联网的发展，图片作为最直观的内容展示方式逐渐在系统中占用越来越多的版面，但是随之而来的就是系统性能的大幅度下滑。传统的JPEG、PNG、GIF各有优点，也各有弊端，“大一统”的图片格式被需要，于是WebP诞生了。

需求

WebP格式文件产生的原因主要是源于对网络图像传输效率的需求以及现有图像格式在某些方面的局限性。

在现代互联网网页中图片和视频占据了很大比例。为了提供更吸引人的用户体验，网站需要加载大量的高质量图像。

同时智能手机和平板电脑的普及推动了移动互联网的快速发展。在移动设备上，网络速度通常比桌面端慢，且用户的流量是有限的。

而JPEG、PNG和GIF等传统图像格式各有其优点，但也存在不足之处。

例如，JPEG虽然非常适合照片，但仅支持有损压缩且不支持透明度；PNG支持透明度但文件大小通常较大；GIF支持动画但色彩范围有限，且文件体积相对较大。

产生

WebP是一种由Google开发的图像文件格式，旨在提供更高效的图片压缩，适用于网络图像传输和展示。

局限

使用

在线格式转换

程序格式转换

Python：可以使用Pillow库（PIL的一个分支）结合webp的支持来进行转换。

// 安装 pip install Pillow



from PIL import Image

im = Image.open("input.png")

im.save("output.webp", "WEBP")

也可以使用Node.js来转换。

这里使用egg.js作为服务端框架

前端

<template>

    <div class="wrap">

        <a-upload

            v-model:file-list="fileList"

            name="file"

            action="/api/uploadImg"

            :accept="['.jpeg','.png','.jpg','.gif']"

            @change="handleChange"

        >

            <a-button>

                上传文件

            </a-button>

        </a-upload>



        <div class="diff-wrap">

            <div class="old-img">

                <img style="max-width: 400px;max-height: 500px;" :src="oldImg" alt=""/>

            </div>

            <div class="new-img">

                <img style="max-width: 400px;max-height: 500px;" :src="newImg" alt=""/>

            </div>

        </div>

    </div>

</template>



<script setup>

import { ref } from 'vue';

const oldImg = ref('');

const newImg = ref('');



const handleChange = info => {

    const file = info.file;



    // 使用 FileReader 进行本地文件预览（无论上传是否成功）

    const reader = new FileReader();

    reader.onload = () => {

        oldImg.value = reader.result; // 将本地文件的 Base64 赋值给 oldImg

    };

    reader.readAsDataURL(file.originFileObj); // 读取原始文件对象



    // 原有上传完成逻辑可保留用于处理服务器返回结果

    if (file.status === 'done' && file.response) {

        console.log(file)

        newImg.value = file.response.url; // 如果上传成功，使用服务器返回的 URL

    }

};



const fileList = ref([]);

</script>



<style scoped>

.diff-wrap {

    width: 800px;

    margin: 20px auto;

    border: 1px solid #ddd;

    display: flex;

}



.old-img {

    flex: 1;

    height: 500px;

    border-right: 1px solid #ddd;

}



.new-img {

    flex: 1;

    height: 500px;

}

</style>

服务端

使用 Node.js 的图像处理库 sharp 进行格式转换，安装 sharp。

npm install sharp

示例代码

const { Service } = require('egg');

const fs = require('fs');

const path = require('path');

const sharp = require('sharp');



class HomeService extends Service {

    async index() {

        return 'hello world';

    }



    async uploadImg() {

        const { ctx } = this;



        try {

            // 1. 获取上传的文件流

            const stream = await ctx.getFileStream();



            // 2. 检查是否为支持的图片格式（可选）

            const allowedMimes = [ 'image/jpeg', 'image/png', 'image/gif', 'image/webp' ];

            if (!allowedMimes.includes(stream.mime)) {

                throw new Error('Unsupported image format');

            }



            // 3. 定义路径

            const tempInputPath = path.join(this.config.baseDir, 'app/public', `temp_${Date.now()}.tmp`);

            const outputFilename = `converted_${Date.now()}.webp`;

            const outputFilePath = path.join(this.config.baseDir, 'app/public', outputFilename);



            // 4. 写入临时原始文件

            const writeStream = fs.createWriteStream(tempInputPath);

            await new Promise((resolve, reject) => {

                stream.pipe(writeStream);

                stream.on('end', resolve);

                stream.on('error', reject);

            });



            // 5. 使用 sharp 转换为 webp

            await sharp(tempInputPath)

                .webp({ quality: 80 }) // 可设置压缩质量

                .toFile(outputFilePath);



            // 6. 清理临时文件

            fs.unlinkSync(tempInputPath);



            // 7. 返回 WebP 图片地址

            return {

                url: `/public/${outputFilename}`,

                filename: outputFilename,

            };

        } catch (err) {

            ctx.logger.error('Image upload or conversion failed:', err);

            throw new Error('Image processing failed: ' + err.message);

        }

    }

}



module.exports = HomeService;

前言

Tauri 2.0 正式版终于在 2024 年 10 月 2 日正式发布了。这次重大更新不仅带来了令人兴奋的新特性，更是为跨平台应用开发开辟了一条全新的道路。让我们一起来看看这个重量级版本带来了哪些惊喜！

1.移动端支持：拥抱全平台时代

Tauri 2.0 最引人注目的特性莫过于对 iOS 和 Android 的全面支持。现在，您可以用同一套代码库开发桌面端（Windows、macOS、Linux）和移动端应用，真正实现"一次编写，到处运行"的梦想。这不仅大大提高了开发效率，还为您的应用打开了更广阔的市场。

2.插件系统升级：灵活性与可扩展性的完美结合

新版本中，Tauri 将大量核心功能转移到了插件中。这意味着您可以根据需求自由选择功能，让应用更加轻量化。同时，插件系统的改进也为社区贡献打开了大门，期待看到更多创新的插件涌现。Tauri 2.0 的插件系统不仅更加灵活,还提供了丰富的官方插件,满足各种开发需求。以下是部分官方插件及其功能:

• 自动启动 (Autostart): 让您的应用在系统启动时自动运行。


• 条形码扫描器 (Barcode Scanner): 在移动应用中使用相机扫描二维码和条形码。


• 生物识别 (Biometric): 在Android和iOS上进行生物识别认证。


• 剪贴板 (Clipboard): 读取和写入系统剪贴板。


• 命令行接口 (CLI): 解析命令行参数。


• 深度链接 (Deep Linking): 将您的Tauri应用设置为特定URL的默认处理程序。


• 对话框 (Dialog): 用于打开/保存文件和显示消息的原生系统对话框。


• 文件系统 (File System): 访问文件系统。


• 全局快捷键 (Global Shortcut): 注册全局快捷键。


• HTTP客户端: 使用Rust编写的HTTP客户端。


• 本地主机 (Localhost): 在生产应用中使用本地主机服务器。


• 日志 (Logging): 可配置的日志记录。


• NFC: 在Android和iOS上读写NFC标签。


• 通知 (Notifications): 向用户发送原生通知。


• 操作系统信息 (OS Information): 读取操作系统信息。


• 持久化作用域 (Persisted Scope): 在文件系统中持久化运行时作用域更改。


• 定位器 (Positioner): 将窗口移动到常用位置。


• 进程 (Process): 访问当前进程。


• Shell: 使用默认应用程序管理文件和URL,以及生成子进程。


• 单实例 (Single Instance): 确保Tauri应用同时只运行一个实例。


• SQL: 提供前端与SQL数据库通信的接口。


• 存储 (Store): 持久化的键值存储。


• Stronghold: 加密、安全的数据库。


• 系统托盘 (System Tray): 系统托盘功能。


• 更新器 (Updater): Tauri应用的应用内更新。


• 上传 (Upload): 通过HTTP进行文件上传。


• WebSocket: 在JavaScript中使用Rust客户端打开WebSocket连接。


• 窗口自定义 (Window Customization): 自定义窗口外观和行为。


• 窗口状态 (Window State): 保存窗口大小和位置。

这些插件涵盖了从基础功能到高级特性的广泛范围,让开发者能够根据项目需求灵活选择。通过这种模块化的方式，Tauri不仅保持了核心框架的轻量级，还为开发者提供了强大的扩展能力。无论您是开发一个简单的工具还是复杂的企业级应用，Tauri的插件系统都能满足您的需求。

3.安全性大幅提升：告别allowlist，迎接新的权限系统

Tauri 2.0 抛弃了旧的 allowlist 系统，引入了更加灵活和强大的权限、作用域和功能系统。这不仅提高了安全性，还让开发者能够更精细地控制应用的权限。值得一提的是，Tauri 还通过了独立的安全审计，让您使用起来更加放心。

4.性能优化：IPC层重写，更快更强

通过重写进程间通信（IPC）层，Tauri 2.0现在支持原始有效载荷，这意味着在前端和后端之间传输大量数据时，性能得到了显著提升。如果您的应用需要处理大量数据，这个特性绝对不容错过。

5.开发体验升级：HMR支持更给力

热模块替换（HMR）现在扩展到了移动设备和模拟器。这意味着您可以实时预览应用在不同设备上的表现，大大加速了开发和调试过程。

6.分发更简单：一站式解决方案

Tauri 2.0提供了详尽的分发指南，覆盖了从App Store到Google Play，再到Microsoft Store等多个平台。无论您的目标市场在哪里，Tauri都能帮您轻松应对。

结语

Tauri 2.0 的正式发布无疑是跨平台开发领域的一个重要里程碑。它不仅延续了 Tauri 一贯的轻量、快速的特点，还通过移动端支持、增强的插件系统和改进的安全机制等特性，为开发者提供了更强大、更灵活的工具。

如果您正在寻找一个能够同时覆盖桌面端和移动端的开发框架，Tauri 2.0绝对值得一试。它不仅能帮您节省时间和资源，还能为您的应用带来卓越的性能和安全性。

参考文章

v2.tauri.app/blog/tauri-…

v2.tauri.app/blog/tauri-…

Flutter 3.24 版本引入了 Flutter GPU 概念的新底层图形 API flutter_gpu ，还有 flutter_scene 的 3D 渲染支持库，它们目前都是预览阶段，只能在 main channel 上体验，并且依赖 Impeller 的实现。

Flutter GPU 是 Flutter 内置的底层图形 API，它可以通过编写 Dart 代码和 GLSL 着色器在 Flutter 中构建和集成自定义渲染器，而无需 Native 平台代码。

目前 Flutter GPU 处于早期预览阶段并只提供基本的光栅化 API，但随着 API 接近稳定，会继续添加和完善更多功能。

详细说，Flutter GPU 是 Impeller 对于 HAL 的一层很轻的包装，并搭配了关于着色器和管道编排的自动化能力，也通过 Flutter GPU 就可以使用 Dart 直接构建自定义渲染器。

Flutter GPU 和 Impeller 一样，它的着色器也是使用 impellerc 提前编译，所以 Flutter GPU 也只支持 Impeller 的平台上可用。

Impeller 的 HAL 和 Flutter GPU 都没打算成为类似 WebGPU 这样的正式标准，相反，Flutter GPU 主要是由 Flutter 社区开发和发展，专职为了 Flutter 服务，所以不需要考虑「公有化」的兼容问题。

在 Flutter GPU 上，可直接从 Dart 与 Impeller 的 HAL 对话，甚至 Impeller Scene API（3D）也将作为重写的一部分出现。

说人话就是，可以用 Dart 通过 Flutter GPU 直接构建自定义渲染效果，未来直接支持 3D

可能有的人对于 Impeller 的整体结构和 HAL 还很模式无法理解，那么这里我们简单过一下：

• 在 Framework 上层，我们知道 Widget -> Element -> RenderObject -> Layer 这样的过程，而后其实流程就来到了 Flutter 自定义抽象的 DisplayList


• DisplayList 帮助 Flutter 在 Engine 做了接耦，从而让 Flutter 可以在 skia 和 Impeller 之间进行的切换


• 之后 Impeller 架构的顶层是 Aiks，这一层主要作为绘图操作的高级接口，它接受来自 Flutter 框架的命令，例如绘制路径或图像，并将这些命令转换为一组更精细的 “Entities”，然后转给下一层。


• Entities Framework，它是 Impeller 架构的核心组件，当 Aiks 处理完命令时生成 Entities 后，每一个 Entity 其实就是渲染指令的独立单元，其中包含绘制特定元素的所有必要信息（编码位置、旋转、缩放、content object），此时还不能直接作用于 GPU


• HAL（Hardware Abstraction Layer） 则为底层图形硬件提供了统一的接口，抽象了不同图形 API 的细节，该层确保了 Impeller 的跨平台能力，它将高级渲染命令转换为低级 GPU 指令，充当 Impeller 渲染逻辑和设备图形硬件之间的桥梁。

所以 HAL 它包装了各种图形 API，以提供通用的设备作业调度接口、一致的资源管理语义和统一的着色器创作体验，而对于 Impeller ， Entities (2D renderer) 和 Scene (3D renderer) 都是直接通过 HAL 对接，甚至可以认为，Impeller 的 HAL 抽象并统一了 Metal 和 Vulkan 的常见用法和相似结构。

Unity 现在也有在 C# 直接向用户公开其 HAL 版本，称为 "Scriptable Render Pipeline" ，并提供了两个基于该 API 构建的默认渲染器 "Universal RP" / "High Definition RP" 用于服务不同的场景，所以 Unity 开发可以从使用这些渲染器去进行修改或扩展一些特定渲染需求。

而在 Flutter 的设计上，Flutter GPU 会作为 Flutter SDK 的一部分，并以 flutter_gpu 的 Dart 包的形式提供使用。

当然，Flutter GPU 由 Impeller 支持，但重要的是要记住它不是 Impeller ，Impeller 的 HAL 是私有内部代码与 Flutter GPU 的要求非常不同， Impeller 的私有 HAL 和 Flutter GPU 的公共 API 设计之间是存在一定差异化实现，而前面的流程，如 Scene (3D renderer) ，也可以被调整为基于 Flutter GPU 的全新模式实现。

而通过 Flutter GPU，如曾经的 Scene (3D renderer) 支持，也可以被调整为基于 Flutter GPU 的全新模式实现，因为 Flutter GPU 的 API 允许完全控制渲染通道附件、顶点阶段和数据上传到 GPU。这种灵活性对于创建复杂的渲染解决方案（从 2D 角色动画到复杂的 3D 场景）至关重要。

Flutter GPU 支持的自定义 2D 渲染器的一个很好的用例：依赖于骨骼网格变形的 2D 角色动画格式。

Spine 2D 就是一个很好的例子，骨骼网格解决方案通常具有动画剪辑，可以按层次结构操纵骨骼的平移、旋转和缩放属性，并且每个顶点都有几个相关的“bone weights”，这些权重决定了哪些骨骼应该影响顶点以及影响程度如何。

使用像 drawVertices 这样的 Canvas 解决方案，需要在 CPU 上对每个顶点应用骨骼权重变换，而 使用 Flutter GPU，骨骼变换可以用统一数组或纹理采样器的形式发送到顶点着色器，从而允许根据骨架状态和每个顶点的 “bone weights” 在 GPU 上并行计算每个顶点的最终位置。

使用 Flutter GPU

首先你需要在最新的 main channel 分支，然后通过 flutter pub add flutter_gpu --sdk=flutter 将 flutter_gpu SDK 包添加到你的 pubspec。

为了使用 Flutter GPU 渲染内容，你会需要编写一些 GLSL 着色器，Flutter GPU 的着色器与 Flutter 的 fragment shader 功能所使用的着色器具有不同的语义，特别是在统一绑定方面，还需要定义一个顶点(vertex)着色器来与 fragment shader 一起使用，然后配合 gpu.ShaderLibrary 等 API 就可以直接实现 Flutter GPU 渲染。

当然，本篇不会介绍详细的 API 使用 ，这里只是单纯做一个简单的介绍，目前 Flutter GPU 进行光栅化的简单流程如下：

• 获取 GPUContext。


• GpuContext.createCommandBuffer 创建一个 CommandBuffer


• CommandBuffer.createRenderPass 创建一个 RenderPass


• 使用各种方法设置状态/管道并绑定资源 RenderPass


• 附加绘图命令 RenderPass.draw


• CommandBuffer 使用 CommandBuffer.submit (异步)提交绘制，所有 RenderPass 会按照其创建顺序进行编码

·····

///导入 flutter_gpu

import 'package:flutter_gpu/gpu.dart' as gpu;



ByteData float32(List<double> values) {

  return Float32List.fromList(values).buffer.asByteData();

}



ByteData float32Mat(Matrix4 matrix) {

  return Float32List.fromList(matrix.storage).buffer.asByteData();

}



class TrianglePainter extends CustomPainter {

  TrianglePainter(this.time, this.seedX, this.seedY);



  double time;

  double seedX;

  double seedY;



  @override

  void paint(Canvas canvas, Size size) {

    /// Allocate a new renderable texture.

    final gpu.Texture? renderTexture = gpu.gpuContext.createTexture(

        gpu.StorageMode.devicePrivate, 300, 300,

        enableRenderTargetUsage: true,

        enableShaderReadUsage: true,

        coordinateSystem: gpu.TextureCoordinateSystem.renderToTexture);

    if (renderTexture == null) {

      return;

    }



    final gpu.Texture? depthTexture = gpu.gpuContext.createTexture(

        gpu.StorageMode.deviceTransient, 300, 300,

        format: gpu.gpuContext.defaultDepthStencilFormat,

        enableRenderTargetUsage: true,

        coordinateSystem: gpu.TextureCoordinateSystem.renderToTexture);

    if (depthTexture == null) {

      return;

    }



    /// Create the command buffer. This will be used to submit all encoded

    /// commands at the end.

    final commandBuffer = gpu.gpuContext.createCommandBuffer();



    /// Define a render target. This is just a collection of attachments that a

    /// RenderPass will write to.

    final renderTarget = gpu.RenderTarget.singleColor(

      gpu.ColorAttachment(texture: renderTexture),

      depthStencilAttachment: gpu.DepthStencilAttachment(texture: depthTexture),

    );



    /// Add a render pass encoder to the command buffer so that we can start

    /// encoding commands.

    final encoder = commandBuffer.createRenderPass(renderTarget);



    /// Load a shader bundle asset.

    final library = gpu.ShaderLibrary.fromAsset('assets/TestLibrary.shaderbundle')!;



    /// Create a RenderPipeline using shaders from the asset.

    final vertex = library['UnlitVertex']!;

    final fragment = library['UnlitFragment']!;

    final pipeline = gpu.gpuContext.createRenderPipeline(vertex, fragment);



    encoder.bindPipeline(pipeline);



    /// (Optional) Configure blending for the first color attachment.

    encoder.setColorBlendEnable(true);

    encoder.setColorBlendEquation(gpu.ColorBlendEquation(

        colorBlendOperation: gpu.BlendOperation.add,

        sourceColorBlendFactor: gpu.BlendFactor.one,

        destinationColorBlendFactor: gpu.BlendFactor.oneMinusSourceAlpha,

        alphaBlendOperation: gpu.BlendOperation.add,

        sourceAlphaBlendFactor: gpu.BlendFactor.one,

        destinationAlphaBlendFactor: gpu.BlendFactor.oneMinusSourceAlpha));



    /// Append quick geometry and uniforms to a host buffer that will be

    /// automatically uploaded to the GPU later on.

    final transients = gpu.HostBuffer();

    final vertices = transients.emplace(float32(<double>[

      -0.5, -0.5, //

      0, 0.5, //

      0.5, -0.5, //

    ]));

    final color = transients.emplace(float32(<double>[0, 1, 0, 1])); // rgba

    final mvp = transients.emplace(float32Mat(Matrix4(

          1, 0, 0, 0, //

          0, 1, 0, 0, //

          0, 0, 1, 0, //

          0, 0, 0.5, 1, //

        ) *

        Matrix4.rotationX(time) *

        Matrix4.rotationY(time * seedX) *

        Matrix4.rotationZ(time * seedY)));



    /// Bind the vertex data. In this case, we won't bother binding an index

    /// buffer.

    encoder.bindVertexBuffer(vertices, 3);



    /// Bind the host buffer data we just created to the vertex shader's uniform

    /// slots. Although the locations are specified in the shader and are

    /// predictable, we can optionally fetch the uniform slots by name for

    /// convenience.

    final mvpSlot = pipeline.vertexShader.getUniformSlot('mvp')!;

    final colorSlot = pipeline.vertexShader.getUniformSlot('color')!;

    encoder.bindUniform(mvpSlot, mvp);

    encoder.bindUniform(colorSlot, color);



    /// And finally, we append a draw call.

    encoder.draw();



    /// Submit all of the previously encoded passes. Passes are encoded in the

    /// same order they were created in.

    commandBuffer.submit();



    /// Wrap the Flutter GPU texture as a ui.Image and draw it like normal!

    final image = renderTexture.asImage();



    canvas.drawImage(image, Offset(-renderTexture.width / 2, 0), Paint());

  }



  @override

  bool shouldRepaint(covariant CustomPainter oldDelegate) {

    return true;

  }

}



class TrianglePage extends StatefulWidget {

  const TrianglePage({super.key});



  @override

  State<TrianglePage> createState() => _TrianglePageState();

}



class _TrianglePageState extends State<TrianglePage> {

  Ticker? tick;

  double time = 0;

  double deltaSeconds = 0;

  double seedX = -0.512511498387847167;

  double seedY = 0.521295573094847167;



  @override

  void initState() {

    tick = Ticker(

      (elapsed) {

        setState(() {

          double previousTime = time;

          time = elapsed.inMilliseconds / 1000.0;

          deltaSeconds = previousTime > 0 ? time - previousTime : 0;

        });

      },

    );

    tick!.start();

    super.initState();

  }



  @override

  Widget build(BuildContext context) {

    return Column(

      children: <Widget>[

        Slider(

            value: seedX,

            max: 1,

            min: -1,

            onChanged: (value) => {setState(() => seedX = value)}),

        Slider(

            value: seedY,

            max: 1,

            min: -1,

            onChanged: (value) => {setState(() => seedY = value)}),

        CustomPaint(

          painter: TrianglePainter(time, seedX, seedY),

        ),

      ],

    );

  }

}

GpuContext 是分配所有 GPU 资源并调度 GPU 的存在，而 GpuContext 仅有启用 Impeller 时才能访问。

DeviceBuffer 和 Texture 就是 GPU 拥有的资源，可以通过 GPUContext 创建获取，如 createDeviceBuffer 和 createTexture ：

• DeviceBuffer 简单理解就是在 GPU 上分配的简单字节串，主要用于存储几何数据（索引和顶点属性）以及统一数据


• Texture 是一个特殊的设备缓冲区

CommandBuffer 用于对 GPU 上的异步执行进行排队和调度工作。

RenderPass 是 GPU 上渲染工作的顶层单元。

RenderPipeline 提供增量更改绘制所有状态以及附加绘制调用的方法如 RenderPass.draw()

可以想象，通过 Flutter GPU，Flutter 开发者可以更简单地对 GPU 进行更精细的控制，通过与 HAL 直接通信，创建 GPU 资源并记录 GPU 命令，从而最大限度的发挥 Flutter 的渲染能力。

另外，对于 3D 支持的 Flutter Scene ， 可以通过使用 native-assets 来设置 Flutter Scene 的 3D 模型自动导入，通过导入编译模型 .model 之后，就可以通过 Dart 实现一些 3D 的渲染。

import 'dart:math';



import 'package:flutter/material.dart';

import 'package:flutter_scene/camera.dart';

import 'package:flutter_scene/node.dart';

import 'package:flutter_scene/scene.dart';

import 'package:vector_math/vector_math.dart';



void main() {

  runApp(const MyApp());

}



class MyApp extends StatefulWidget {

  const MyApp({super.key});



  @override

  MyAppState createState() => MyAppState();

}



class MyAppState extends State<MyApp> with SingleTickerProviderStateMixin {

  double elapsedSeconds = 0;

  Scene scene = Scene();



  @override

  void initState() {

    createTicker((elapsed) {

      setState(() {

        elapsedSeconds = elapsed.inMilliseconds.toDouble() / 1000;

      });

    }).start();



    Node.fromAsset('build/models/DamagedHelmet.model').then((model) {

      model.name = 'Helmet';

      scene.add(model);

    });



    super.initState();

  }



  @override

  Widget build(BuildContext context) {

    final painter = ScenePainter(

      scene: scene,

      camera: PerspectiveCamera(

        position: Vector3(sin(elapsedSeconds) * 3, 2, cos(elapsedSeconds) * 3),

        target: Vector3(0, 0, 0),

      ),

    );



    return MaterialApp(

      title: 'My 3D app',

      home: CustomPaint(painter: painter),

    );

  }

}



class ScenePainter extends CustomPainter {

  ScenePainter({required this.scene, required this.camera});

  Scene scene;

  Camera camera;



  @override

  void paint(Canvas canvas, Size size) {

    scene.render(camera, canvas, viewport: Offset.zero & size);

  }



  @override

  bool shouldRepaint(covariant CustomPainter oldDelegate) => true;

}

目前 Flutter GPU 和 Flutter Scene 的支持还十分有限，但是借助 Impeller ，Flutter 开启了新的可能，可以说是，Flutter 团队完全掌控了渲染堆栈，在除了自定义更丰富的 2D 场景之外，也为 Flutter 开启了 3D 游戏的可能，2023 年 Flutter Forward 大会的承诺，目前正在被落地实现。

详细 API 使用例子可以参看 ：medium.com/flutter/get…

如果你对 Flutter Impeller 和其着色器感兴趣，也可以看：

• 《快速了解 Flutter 的渲染引擎的优势》


• 《Flutter 里的着色器预热原理》

作者：前端开发爱好者

对于多数前端开发者而言，用 ThreeJS 打造炫酷的数字孪生场景并非易事，需掌握大量专业知识。

如今，一款基于 Vue3、ThreeJS 和 Naive UI 的数字孪生开发框架 ——Astral 3D Editor 正式开源，为 Web3D 开发带来新转机。

Astral 3D Editor 是什么？

Astral 3D Editor 是一款免费开源的三维可视化孪生场景编辑器，主要服务于 Web3D 开发，支持多种常见 3D 模型格式

还具备轻量化 BIM 模型解析及 CAD 图纸预览功能。

Astral 3D Editor 的优势

• 功能丰富 ：支持多种 3D 模型格式，可导入导出多类型模型，方便资源整合。它还提供插件系统，可扩展更多功能。同时，支持在线预览 BIM 模型和 CAD 图纸，为建筑、工程等领域提供便利。粒子系统、动画编辑器等功能一应俱全，满足多样化创作需求。


• 技术先进 ：以 ThreeJS 为底层 3D 渲染库，结合 Vue3 响应式编程和组件化开发，以及 Naive UI 的丰富组件，构建高效稳定的编辑器框架。其场景数据无损压缩和网络分包渐进存取技术，优化了大规模场景的加载效率。


• 开发门槛低 ：作为 3D 低代码创作工具，降低了 Web3D 开发难度，前端开发者无需深入掌握 3D 图形学知识，也能快速创建高质量 3D 场景，提高开发效率。


• 开源友好 ：采用 Apache-2.0 License 开源协议，吸引众多开发者参与，形成活跃开源社区，便于交流分享和共同推动项目发展。

Astral 3D Editor 快速上手

环境准备

在开始使用 Astral 3D Editor 之前，确保已经安装了以下软件和工具：

• Node.js ：建议安装 Node.js ≥ 18.x，可以通过官方链接下载安装。


• Yarn ：一个高效的包管理工具，可以通过官方链接进行安装。

项目克隆与安装

通过 Git 将 Astral 3D Editor 的项目代码克隆到本地：

git clone https://github.com/mlt131220/Astral3DEditor.git

进入项目目录：

cd Astral3DEditor

使用 Yarn 安装项目依赖：

yarn install

项目运行与构建

在开发环境中启动项目：

yarn run dev

这将启动本地开发服务器，通常会自动在浏览器中打开 Astral 3D Editor 的界面，若未自动打开，可在浏览器中访问 http://localhost:3000。

基础操作指南

Astral 3D Editor 的界面简洁直观，主要包含以下几个关键区域：

• 工具栏 ：提供了各种工具按钮，可进行模型导入、视图切换、对象选择和变换等操作。

• 视图区域 ：用于显示和编辑 3D 场景，支持多种视图模式，如透视图、正交图，以及前置、后置、左置、右置等不同视角的切换。

• 属性面板 ：用于查看和编辑当前选中对象的属性，可根据不同对象类型进行相应属性的调整。

Astral 3D Editor 在线编辑器

Astral 3D Editor 的在线编辑器是其一大亮点，提供了便捷的在线 3D 场景创作体验。

在线编辑器无需安装额外软件，只要有浏览器和网络连接，用户就能直接在浏览器中打开: https://editor.astraljs.com/#/，随时随地进行 3D 场景的创作和编辑。

界面设计简洁直观，操作流程简单易懂，降低了学习成本，初学者也能快速上手，轻松进行模型导入、场景编辑、动画添加等操作，迅速构建出想要的 3D 场景。

此外，在线编辑器还具有出色的跨平台兼容性，支持在 Windows、macOS 以及 Linux 等多种操作系统上运行，兼容各大主流浏览器，包括 Chrome、Firefox、Safari 等，用户可自由选择浏览器进行创作。

值得一提的是，在线编辑器支持通过拖拉拽形式创建场景，操作简单直观，大大降低了 3D 场景创作的门槛。

同时，官方还提供了大量可视化案例展示，这些案例不仅丰富多样，而且具有很高的学习价值，可供用户参考学习，帮助用户更好地掌握 3D 场景创作的技巧和方法。

Astral 3D Editor 的开源，为 Web3D 领域注入新活力。

其功能、技术、开发难度、应用场景和开源优势，使其有望在数字孪生领域发挥重要作用，推动 Web3D 技术持续进步。

• Astral 3D Editor Github 地址：https://github.com/mlt131220/Astral3DEditor


• Astral 3D Editor 在线编辑器：https://editor.astraljs.com/#/


• Astral 3D Editor 官方文档：http://editor-doc.astraljs.com/

感谢由 Pixso 资源社区提供的共享作品 《Dompet数字页面设计》

推荐

使用 Harmony ArkTS 开发数字钱包应用（Dompet App）

前言

早在几年前，我有幸参与了公司 App 的技术选型，并决定采用 Flutter 技术栈，快速从零搭建出能够集成 H5 应用的 混合应用框架（Hybrid App）。在这个过程中，得益于 Flutter 跨平台特性和高效的 UI 构建能力，我们在短时间内实现了一个功能丰富的混合应用，支持 H5 应用扫码、支付、定位等设备能力。

随着需求的不断迭代与升级，原本的 App 逐渐变得 “臃肿” 起来。回顾当初搭建的 Flutter 混合应用框架，虽然满足了业务上的需求，但在架构设计上显得略为粗糙。面对日益增加的技术负债，依靠业余时间进行优化和重构已然心有余而力不足。是时候重新搭建开发 Flutter 混合应用框架，以便更好的引入最新技术，快速适配各业务场景，提升 App 开发和运行效率。

选型

在构建 Flutter 混合应用 App 的过程中，基于 状态管理、依赖注入、路由管理 和 国际化（i18n） 等考虑，我们首先选择了 GetX 作为核心框架。随后，为了确保 App 具备 网络请求、本地持久化存储、本地数据库管理 以及 Webview 等能力，我们进一步引入了 dio、get_storage、sqflite 和 flutter_inappwebview 等插件。

然而，开发 App 仅仅依靠 Flutter 技术栈是远远不够的，我们还需要一个具有良好用户体验和精美 UI 界面的设计稿。可惜设计不是我所擅长的领域，好在 Pixso 资源社区提供了丰富的共享作品，在那里我找到了适合我的 UI 设计 《Dompet 数字钱包》

这套设计稿具备以下优点：

特性

在技术上，我们选择了 GetX、dio、sqflite、get_storage 以及 flutter_inappwebview 作为构建框架的核心基础设施，而在 UI 设计方面，则是选择了 《Dompet 数字钱包》 设计稿作为我们 App 用户界面。

在确定了 Flutter 技术栈、核心插件以及 UI 设计稿后，我们开始着手梳理 Dompet 数字钱包 的 UI 界面和功能需求，以确保高效的开发效率，并成为一个用户体验极佳的 App。

重要插件依赖如下：

• flutter_ringtone_player: (系统提示音，用于转账、支付、充值成功时的系统提示)


• flutter_inappwebview: (App Webview, 用于访问 H5 Web 应用)


• google_sign_in: (Google 账号免密登录，用于实现便捷的用户身份验证)


• firebase_core: (Firebase 的核心依赖，为其他 Firebase 服务提供基础支持)


• firebase_auth: (Firebase 平台认证，支持多种认证方式，目前用到了 Google 和 GitHub)


• path_provider: (获取应用的常用存储路径，例如：临时目录、文档目录)


• fluttertoast: (用于在应用中显示短暂的消息提示，支持error、warnning、 success)


• image_picker: (用于选择和拍摄图片或视频，方便用户上传和处理媒体文件)


• get_storage: (轻量级的本地存储解决方案，用于存储简单数据，如用户登录状态)


• fl_chart: (用于绘制各类图表，如折线图、柱状图等，方便可视化数据展示)


• sqflite: (Flutter 的 SQLite 插件，用于在本地存储和管理结构化数据)


• intl: (国际化和本地化支持库，帮助处理不同语言和区域格式的数据)


• dio: (强大的 HTTP 客户端，支持各种请求方式、拦截器和响应处理，适用于网络请求)


• get: (用于状态管理、依赖注入和路由管理，提供简单而高效的开发体验)

源码 - 插件封装

• lib/configure/dio: 封装了 Request 和 Response 拦截处理 (携带 Token、异常处理等)


• lib/configure/sqflite: 封装定义 Sqfliter 为 App 创建、打开、关闭、删除 sqlite，提供便捷的 Api


• lib/configure/fluttertoast: 封装定义了通用的 Toaster，支持 error、warning、success 三种消息体


• lib/configure/get_translate: 借助 GetX 定义 JsonTranslations, 解析 JSON 数据格式的多语言国际化


• lib/configure/image_picker: 封装定义 MediaPicker 便于 App 从用户设备的相册中选择图片或视频


• lib/configure/path_provider: 封装定义 PathProvider 为 App 提供了便捷的 Api 来访问这些系统目录

源码 - Extension 扩展

• lib/extension/date: 为不同语言和地区提供日期本地化格式方案 (eg. US: Oct 4, 2024)


• lib/extension/bool: 为 Dart 所有类型转换 bool 类型，提供了便捷方案 (eg. 'string'.bv => true)


• lib/extension/money: 定义提供了金额显示的多种方式 USD、usd2 (eg. 1000.usd2 => '$1,000.00')


• lib/extension/size: 适配不同设备的屏幕以及屏幕翻转时自适应，定义多种单位 (wdp、wmax、sr ...)

源码 - 全局应用服务

• lib/service/event: 定义了全局的事件。例如 登录、退出、更新用户信息，创建订单、创建消息等


• lib/service/locale: 定义存储了全局的 locale、以及语言国际化处理。如切换中英文、使用系统语言


• lib/service/media: 定义储存了 mediaQuery 状态，借助 .obs 实现 UI 自动更新 (如 设备翻转时)


• lib/service/native: 定义创建了 Flutter Dart 与 原生 IOS、Android 端 的 MethodChannel 消息通道


• lib/service/sqlite: 定义创建了 App 本地数据库(sqlite)，并为不同的用户账号分配各自数据库资源


• lib/service/store: 定义维护了全局数据存储 (例如 用户、订单、银彳亍卡...)，并自动同步 UI 更新


• lib/service/webview: 定义创建了 Flutter 与 Webview 端的 WebviewChannel，类似 JS Bridge

遗憾

在开发过程中，虽然我们通过 Flutter 技术栈和丰富的插件实现了许多功能，但仍遇到了一些不尽如人意的地方，特别是在集成 国内支付 (微信支付、支付宝) 上。国内支付必须通过企业或第三方服务商，且得有资质情况下，才能完成支付认证和集成，对个人开发者并不太友好。

此外，这次 数字钱包应用 的开发，主要目的是为了探索和搭建 Flutter App 框架，并没有计划将其上架。因此，我们暂时没有进行 App 订阅 功能的集成和测试，这也算是项目中的一个小遗憾。对于 App 订阅 的实现与集成，我们没有实际的开发经验。如果有熟悉这方面的朋友，欢迎在评论区留言分享，感谢！

注意

如果你对 数字钱包应用 感兴趣，想从 Github 下载下来，运行在自己的设备上。需要注意的是，无论是账号密码的登录注册，还是 Google 或 Github 的便捷登录，因为使用了 Firebase 平台的认证，在国内你可能需要 VPN，否则 数字钱包应用 可能会因网络问题而卡死。

有关这个问题的 issues 如下:

https://github.com/flutter/flutter/issues/70427 前往

演示

https://linpengteng.github.io/resource/dompet-app/app.gif 前往

GitHub

Dompet App: https://github.com/DompetApp/Dompet.flutter 前往

Webview SDK: https://github.com/DompetApp/Dompet.webview 前往

前往这个项目，给个 Star 👍

最近鸿蒙 PC 刚发布完，但是发布会没公布太多技术细节，基本上一些细节都是通过自媒体渠道获取，首先可以确定的是，鸿蒙 PC 本身肯定是无法「直接」运行 win 原本的应用，但是可以支持手机上「原生鸿蒙」的应用，细节上无非就是 UI 兼容下大屏模式的支持，比如下图是来自 差评XPIN 的鸿蒙 PC 截图：

那么问题来了，HarmonyOS 「卓易通 」 作为生态过渡的丰富支持，甚至在应用商店都可以无缝衔接，那么鸿蒙 PC 是否也可以有类似的场景？

因为目前得到的消息是，鸿蒙 PC 不支持侧载 ，这个结论我也不保熟，只是在这个大条件下讨论，那么 鸿蒙 PC 是不是也可以有个 「W易通」？技术上是否可以支持？

当然，你要说鸿蒙 PC 和鸿蒙手机，本质它们是同源的，App 之间互通理论上没毛病，从这个角度看，好像又支持侧载？

那「W易通」？技术上是否可以支持？答案上还真可以，从某些媒体上说的，通过定制 Wine 来兼容已有的 win 软件，这个或许是一条可行的路，但是其实我也并没有找到官方下图的说法和出处，但是不妨碍我们讨论可行性。

Wine 这个名字本身就揭示了它核心特性：“Wine Is Not an Emulator”（Wine 不是模拟器），它其实已经被应用很久了，例如：

• Steam Deck 和 Proton，就是那个 Steam 的掌机，它用的就是为极致游戏定制的 Wine ，Proton 是一个为 Windows 游戏能在 Linux 上流畅运行而深度定制和优化的发行套件


• CrossOver 和 Whiskey，在 macOS 上运行 win 游戏，也是 Wine 的定制

所以 Wine 确实是一个可行的途径，Wine 在实际场景里主要是充当一个兼容层，实时地将 Windows 应用的 API 调用转换为宿主操作系统（如 Linux 或 macOS）能够理解的等效 POSIX 调用 。

当然，这种设计也意味着 Wine 的兼容性直接取决于其对 Windows API 的重实现程度，所以 Wine 的核心就是重塑 Windows API ，在某种程度上镜像了 Windows 的结构，例如：

• wineserver：在 Windows 中主要是由内核提供核心服务，在 Wine 中会由 wineserver 在用户空间实现 ，它的职责包括实现基本的 Windows 功能，如进程和线程管理、对象管理、进程间通信（IPC）、同步原语、将 Unix 信号转换为 Windows 异常，处理窗口管理和输入事件等


• 核心 DLL 的重实现：Wine 提供了大量核心 Windows DLL 版本，例如 NTDLL.DLL（Windows NT 内核功能的核心接口）、KERNEL32.DLL（基础操作系统功能，如内存管理、文件 I/O）、GDI32.DLL（图形设备接口，负责 2D 绘图）、USER32.DLL（用户界面元素、窗口管理、消息传递）等 ，这些 Wine 实现的 DLL 通常以 Unix 共享对象（.so 文件）的形式存在，它们可以直接调用宿主操作系统的函数

另外 还有 WineD3D ，将 Direct3D 和 DirectDraw API 调用翻译成 OpenGL 调用的核心组件 ，另外还有 DXVK 这种专注于将 Direct3D API 调用高效地翻译成 Vulkan 调用的支持。

前面的 Steam 的 Proton 也是一个针对游戏优化的 vkd3d 分支，负责将 D3D12 调用翻译为 Vulkan ，而 macOS 上或者还需要比如 MoltenVK 将 Vulkan 转为 Metal ？

当然，翻译 API 的局限性就不用多说了，还有一些依赖底层驱动支持的场景，很难在通用性上做到完美，当时理论上做到部分应用通用的场景应该可以，甚至在游戏领域反而更有优势？

当然，还有另外一条途径就是直接跑虚拟机，或者说虚拟桌面，目前已经有不少人运行成功，比如就有博主用 Os-easy 虚拟机装上了Windows 11 ：

事实上 Linux 上运行 Win 虚拟机一直以来就有，用户只需选择镜像文件并完成基础配置，同样也可以在鸿蒙 PC 上使用Windows系统。

安装完成后，用户可以在鸿蒙与 Windows 系统之间便捷切换，类似切换桌面的效果，这样也算是一种场景支持：

当然，虚拟桌面的割裂感会更重，但是在通用软件场景下会相对更好，但是性能也许会更差一下？

另外，目前也挺多觉得鸿蒙 PC 就是一个平板 PC 化的场景，其实这样也算是一个趋势？类似我前段时间一直在聊的 Android PC 化支持，目前 Android 桌面化已经集齐：

• Linux 终端控制台支持


• 桌面模式


• 外部显示器支持


• 窗口多任务，最小化，多实例支持


• 尚未明确的 Desktop View


• 外部显示器排列和切换


• ·····

例如下方就是 Android 下的外部显示器排列和切换支持：

最后，貌似目前鸿蒙 PC 虽然能进终端，但是不开放 sudo 权限，apt 也没有？这部分能力不知道后续是否会开放，从 PC 角度看这部分能力还是有必要的：

比如小米这个 winplay 是不是也是 wine 的定制魔改？我个人感觉，鸿蒙 pc 上游戏通过 wine 体系支持可能会比虚拟桌面更好？

那么，对于鸿蒙 PC 场景，你有什么技术方向想聊的？

可能是临近假期，昨天眼睛乱晃时，偶然间在我的办公桌角落上发现一罐红牛。当我看到它的第一眼，就想起了很多事情。我知道它已经过期很久了，我还能模糊地想起当年隔壁部门领导送给我们的那个场景，也还能想起早已离职的同事们相处的日常……

这罐红牛啊，过期很久咯

但当我拿过来仔细一看的时候，才有点感慨，我知道它过期很久了，但没想到已经过期快 7 年了。也就是说，我来这个公司已经快 9 年了。作为一个2016年软件工程985本科毕业的年轻人，守在一个工厂拿着远远远低于行业平均水平的死工资，居然已经快 9 年了。我甚至敏感到与这罐红牛“感同身受”。

• 年轻时，无穷的精力和旺盛的斗志，对未来也是无限美好的憧憬，根本不需要红牛来提神。


• 过几年，经历越来越多的挫败和不如意，发现事情越来越不受自己控制，一罐红牛能起什么用。


• 后来啊，感觉自己前途和命运(身体与灵魂)都不属于自己、无法掌握，一罐红牛又算什么东西。


• 现在啊，孙连城是对的，就应该多看星星，“胸怀宇宙”，相比之下一切都是小事，红牛本来就只是用来提神的。

可惜的是，这罐红牛过期快七年了，它还能再提神吗？就和薛定谔的猫一样，不在困倦的时候去喝掉这罐红牛，我根本不会知道它还能不能提神。但是呢，我不敢喝。

• 如果只是想要提神，再买一罐没过期的就好了。但是这罐过期的红牛，再也回不到没过期了。
  
  
  
  • 就像我在这工厂呆了九年，也三十多了，再也回不到二十多岁的时候了。但永远都有充满无限精力、天真稚嫩的二十多岁的小伙子。
  
  
  
  


• 或许只是我还把它遗忘在办公桌的角落，所以它还存在；换成别人，可能早就喝掉了；或者也放过期，但是也早扔掉了；罐子可能回收利用，继续发光发热，也可能埋在哪个角落，慢慢副食氧化……
  
  
  
  • 会不会也偶尔觉得自己“空有一身济世救人的才华和抱负却无处施展”？像个废物不被重视。
  
  
  
  


• 既然已经放在角落那么多年了，我也打算继续放在那里。那个不起眼的角落，只会占那么小小的一点地方，我不会在意，别人更不会在意。
  
  
  
  • 我不知道我还能在这里待多久，到时候我会带它走吗？可能不会了吧，毕竟它也没什么用了。象征意义大于实际，就像我也不主动联系那些没什么交集、感情不深的老同学、前同事。
  
  
  
  

自怨自艾啊，都知道是没用的

我觉得“最近行情不太好”这个话术，我很久没有去听了，也可能是刻意没有去关注。原因倒也简单，之前还想着说不定好好准备换个“钱多事少离家近”的工作。后来就是“我先保住这份工”，什么事情到时候再说吧。现在我多“乐观”，不管什么事，到时候再说吧。

就像也偶尔看到什么统计数据，结婚登记人数越来越少，离婚登记人数越来越多，“或许大家都还在纳闷不知道为什么呢。”

这很难的，就像我表弟刚工作 3 年，就开始在担心“35 岁危机”。未雨绸缪、眼光长远一点问题没有， 但是呢：

• 要命的是光担心肯定是一点用没有，因为你只是担心、忧虑这个情况，并没有想到应对策略，那真正面临的时候，还是无所适从。


• 更要命的是，不管你担心与否、忧虑与否，这个“危机”一定存在。


• 更更要命的是，你知道，但是解决不了。


• 就像我表妹指着我对表弟所说：“你慌什么，到时候先死的是他。”这一点毛病没有，我是没几年就 35 了，而且我到现在也没有具体应对策略。但更更更要命的是 ，我死了并不能缓解我表弟的担忧，看着我毫无办法或许更加重他的忧虑。

那我还会担心吗？偶尔吧。毕竟就像以前所说的，我与自己和解了，认清了现实，接受了平凡而普通的自己。可惜的是自己看清楚了，好像并没有很大的用处，因为似乎现代人很难作为一个独立的个体而生存。简单说起来就是"帅哥/美女与金钱"(爱情和事业)。

• 我一个月倒还想拿个几百万呢，但是老板不给我啊？什么，我为什么不去当老板？


• 我也想相敬如宾、举案齐眉、儿孙满堂、本枝百世，可还是单身。什么，我为什么不去找对象？

八旬老头老太太经常打电话问我：“你要好久才找对象哦”、“你结婚了我们才放得下心哦”、“我们天天焦得瞌睡都睡不着啊”……

我是很难去回应这种期盼了，甚至有时候不知道他们是真关心我生活，还是因为“你大孙 30 多了还没结婚啊，好搞笑哦”太没面子。毕竟时代不一样了，我可能不接受但可以去理解他们的老思想，但他们却不理解也无法接受我们新时代，就好像他们真的觉得想找对象马上就找的到，想换工作马上就换得到，想长生不老喝口水就可以了一样。

说多了大家都不爱听，所以我一般只会阿巴阿巴。

与自己和解？我只是随口一说

偶尔我会觉得，大部分普通人的人生经历都是类似的，只有那些真正“我命由我不由天”的少数人才的成功，比较难以复制。这也是我认为“经验之谈”大部分时候都是有效的。

可惜的是，经验之谈往往只有个结果，每个人的真正经历的细节不太一样，每个人的理解能力不太一样，时代背景也不一样，导致处理过程可能就不通用了。我说“与自己和解”之后，我的人生畅快了很多，但有些陌生的朋友来和我交流的时候，我却爱莫能助，也只能提个结论。

• 深情是不是舔狗？没钱是不是铁废物？


• “事前同意不代表事后同意”到底是什么原理？


• “我只是希望你上进”到底是什么意思？


• “我真的不想耽误你”到底是不是一片好心？


• “我真的希望你有更好的未来”是不是真心的祝愿？


• ……

“乱花渐欲迷人眼”，很多时候我看不明白，我就不爱看，我就做个“逃避者”，你觉得可耻关我什么事呢。这个时代到底需不需要阿 Q 精神？“只有对社会没用的废物才会想着放假，我们这些栋梁之才一心做建设，根本不需要放假。”

……

这样的生活多累啊，但是作为人的话，本来就很复杂。就像我曾以为我可以大展宏图发光发热，但是我错了；也以为自己遇到了对的人，然后又错了……

事实上，那罐红牛没有思想，我摆在那里，它就在那里，而且一直在那里。它不会开心、不会难过，也不会发表长篇大论咋咋呼呼。而且在那已经过去的8年，不管它是否过期，它都没有意识，它根本不关心，而且其实我也TM根本就不在乎它，全都是我顾影自怜而已。

或许可以试着当一罐过期的红牛？

就像我记得去年四五月的时候，各个云平台的AI大模型API或大幅度降价或者免费，我就在想能不能借助这些资源做个什么东西出来，还给好几个平台充了钱。一年过去了，但还是不知道能拿来做什么，依旧和最初的想法一样，调用各个平台API进行聊天对话而已，其他富有创造性的想法，完全没有。甚至在年初DeepSeek爆火之后，像我充钱的零一万物、智谱AI啥的，都没有特别大的声音。

或许有能力的人，先有超凡的思想，然后又脱俗的能力，所以才是弄潮儿。一年过去了，我还是没有想到能借助AI浪潮搞点什么，最多是用上了cursor并逐渐接纳了它。

但是，不管我怎么看待AI浪潮，它都会发展。就像5G、Web3、元宇宙……你不管以后对它们的定义是什么，它们都有着自己的发展轨迹，可能有的生命周期长点，有的Y轴高点，有的依旧不被很多人看好……

虽然我不是“宇宙区长”，我的生命还有那么长，“人生在世屈指算，也就三万六千天”。但就算到了35岁，也才三分之一，到目前的法定退休也才二分之一，我才进社会多少年，那后面的那些年就不过了？

或许可以当一罐过期的红牛，就默默地待在角落，世间的美好，人性的险恶，都如过眼云烟，我自岿然不动。

或许我只是想当这一罐过期了 7 年、却还没被我丢掉的红牛，可以长久在无人关注的角落，享受着自己孤独的快乐。

最后，还是分享一下我最新版本调用云平台大模型API的聊天应用，万一正好有朋友需要呢。

桌面主页面预览:

移动端截图:

若有兴趣，更具体内容可访问github查看：Sanotsu/SuChat-Lite。

以上，感谢垂阅。

4. 创建应用后点击"添加Key"，复制生成的密钥

这个Key就是打开高德地图宝库的钥匙，下面要把它交给我们的AI助手。

步骤3：配置AI的地图能力

这一步的关键——我们要让AI获得调用高德地图的超能力：

如果你使用的是Claude，添加下面的代码（记得替换成你自己的key）建议重启下应用：

{

  "mcpServers": {

    "amap-maps": {

      "command": "npx",

      "args": ["-y", "@amap/amap-maps-mcp-server"],

      "env": {"AMAP_MAPS_API_KEY": "这里粘贴你的key"}

    }

  }

}

确认配置无误后，AI现在已经具备了调用高德地图的能力，它可以查询实时天气、景点信息、路线规划和交通状况等数据。

步骤4：一句指令，生成完美攻略

现在是见证奇迹的时刻！在对话框中输入：

用高德MCP，做苏州三天旅游指南

然后静静等待几秒钟，AI会开始调用高德地图API，搜集各种数据并为你生成一份详尽的旅行规划。

我的苏州三日游攻略包含了：

• 每天详细的行程安排和时间规划
• 景点介绍、门票价格和开放时间
• 周边餐厅推荐和特色美食
• 不同景点间的交通方式和预计用时
• 三天的天气预报
• 住宿和购物建议
• 各种实用小贴士

最妙的是，AI还能根据天气情况自动调整行程——我看到第二天苏州预报有大雨，它贴心地提醒我准备雨具，并建议安排更多室内活动。

锦上添花：生成打印版旅行攻略

如果你想更进一步，可以让AI为你生成一份精美的A4旅行规划表，方便打印随身携带。

只需输入： 帮我设计一个A4纸张大小的旅行规划表，适合打印出来随身携带

这是我的提示词

# 旅行规划表设计提示词

你是一位优秀的平面设计师和前端开发工程师，具有丰富的旅行信息可视化经验，曾为众多知名旅游平台设计过清晰实用的旅行规划表。现在需要为我创建一个A4纸张大小的旅行规划表，适合打印出来随身携带使用。请使用HTML、CSS和JavaScript代码实现以下要求：

## 基本要求

尺寸与基础结构

   - 严格符合A4纸尺寸（210mm×297mm），比例为1:1.414

   - 适合打印的设计，预留适当的打印边距（建议上下左右各10mm）

   - 采用单页设计，所有重要信息必须在一页内完整呈现

   - 信息分区清晰，使用网格布局确保整洁有序

   - 打印友好的配色方案，避免过深的背景色和过小的字体

技术实现

   - 使用打印友好的CSS设计

   - 提供专用的打印按钮，优化打印样式

   - 使用高对比度的配色方案，确保打印后清晰可读

   - 可选择性地添加虚线辅助剪裁线

   - 使用Google Fonts或其他CDN加载适合的现代字体

   - 引用Font Awesome提供图标支持

专业设计技巧

   - 使用图标和颜色编码区分不同类型的活动（景点、餐饮、交通等）

   - 为景点和活动设计简洁的时间轴或表格布局

   - 使用简明的图示代替冗长文字描述

   - 为重要信息添加视觉强调（如框线、加粗、不同颜色等）

   - 在设计中融入城市地标元素作为装饰，增强辨识度

## 设计风格

- 实用为主的旅行工具风格：以清晰的信息呈现为首要目标

- 专业旅行指南风格：参考Lonely Planet等专业旅游指南的排版和布局

- 信息图表风格：将复杂行程转化为直观的图表和时间轴

- 简约现代设计：干净的线条、充分的留白和清晰的层次结构

- 整洁的表格布局：使用表格组织景点、活动和时间信息

- 地图元素整合：在合适位置添加简化的路线或位置示意图

- 打印友好的灰度设计：即使黑白打印也能保持良好的可读性和美观

## 内容区块

1. 行程标题区：

   - 目的地名称（主标题，醒目位置）

   - 旅行日期和总天数

   - 旅行者姓名/团队名称（可选）

   - 天气信息摘要

2. 行程概览区：

   - 按日期分区的行程简表

   - 每天主要活动/景点的概览

   - 使用图标标识不同类型的活动

3. 详细时间表区：

   - 以表格或时间轴形式呈现详细行程

   - 包含时间、地点、活动描述

   - 每个景点的停留时间

   - 标注门票价格和必要预订信息

4. 交通信息区：

   - 主要交通换乘点及方式

   - 地铁/公交线路和站点信息

   - 预计交通时间

   - 使用箭头或连线表示行程路线

5. 住宿与餐饮区：

   - 酒店/住宿地址和联系方式

   - 入住和退房时间

   - 推荐餐厅列表（标注特色菜和价格区间）

   - 附近便利设施（如超市、药店等）

6. 实用信息区：

   - 紧急联系电话

   - 重要提示和注意事项

   - 预算摘要

   - 行李清单提醒

## 示例内容（基于深圳一日游）

目的地：深圳一日游

日期：2025年4月15日（星期二）

天气：晴，24°C/18°C，东南风2-3级

时间表：

| 时间 | 活动 | 地点 | 详情 |

|------|------|------|------|

| 09:00-11:30 | 参观世界之窗 | 南山区深南大道9037号 | 门票：190元 |

| 12:00-13:30 | 海上世界午餐 | 蛇口海上世界 | 推荐：海鲜、客家菜 |

| 14:00-16:00 | 游览深圳湾公园 | 南山区滨海大道 | 免费活动 |

| 16:30-18:30 | 逛深圳欢乐海岸 | 南山区白石路 | 购物娱乐 |

| 19:00-21:00 | 福田CBD夜景或莲花山夜游 | 福田中心区 | 免费活动 |

交通路线：

- 世界之窗→海上世界：乘坐地铁2号线（世界之窗站→海上世界站），步行5分钟，约20分钟

- 海上世界→深圳湾公园：乘坐公交线路380路，约15分钟

- 深圳湾→欢乐海岸：步行或乘坐出租车，约10分钟

- 欢乐海岸→福田CBD：地铁2号线→地铁4号线，约35分钟

实用提示：

- 下载"深圳地铁"APP查询路线

- 准备防晒用品，深圳日照强烈

- 世界之窗建议提前网上购票避免排队

- 使用深圳通交通卡或移动支付

- 深圳湾傍晚可观赏日落美景和香港夜景

- 周末景点人流较大，建议工作日出行

重要电话：

- 旅游咨询：0755-12301

- 紧急求助：110（警察）/120（急救）

请创建一个既美观又实用的旅行规划表，适合打印在A4纸上随身携带，帮助用户清晰掌握行程安排。

AI会立刻为你创建一个格式优美、信息完整的HTML文档，包含所有行程信息，分区清晰，配色考虑了打印需求，真正做到了拿来即用！

告别旅行规划焦虑症

这套方法彻底改变了我规划旅行的方式。以前要花半天甚至几天的工作，现在10分钟就能完成，而且质量更高：

• 基于实时数据：不会推荐已关闭的景点或过时信息
• 路线最优化：自动计算景点间最合理的游览顺序
• 个性化定制：想要美食之旅？亲子游？文艺路线？只需一句话
• 省时又省力：把宝贵时间用在享受旅行上，而不是规划过程中

最让我满意的是，这整套流程不需要任何编程知识，人人都能轻松上手。我妈妈都能用！

更多玩法等你探索

除了基础攻略，你还可以用更具体的指令获取定制内容：

"我想了解苏州有什么值得打卡的特色美食" "帮我规划一条适合老人和小孩的苏州慢游路线" "我只去苏州一天，哪些景点必须打卡？" "设计一条苏州园林主题的摄影路线"

每一个问题，AI都能结合高德地图的数据给你最专业的建议。

以后旅行前，不用再痛苦地翻攻略、对比信息、反复规划了。一杯咖啡的时间，完美行程就在你手中。

这大概就是科技改变生活的最好证明吧！下次出行，不妨也试试这个方法，让AI做你的专属旅行规划师！

阿里云宣布全面支持MCP服务部署和调用

前天群里还有小伙伴想玩下MCP服务呢，昨天阿里云百炼平台就宣布全面支持MCP服务部署与调用，打通AI应用爆发的最后一公里。

这里是地址：bailian.console.aliyun.com/?tab=mcp#/m…

当然昨晚我也研究了下，简直不要太简单，连注册都省了，下面点立即开通呢就能玩了

下面这个知名爬虫服务我也体验了把，非常简单易懂

创建完应用，提示词录入进去就能用了，连cursor，claude的mcp配置都免了，感兴趣的朋友可以去体验下。

前言

前几天和前同事闲时聚餐，约了两个月的小聚终于达成了，程序员行业聚少离多，所幸大家的发量还坚挺着。

期间不可避免地聊到了自己的公司、行业状况以及对未来的看法，几杯老酒之后，大家畅所欲言，其中一位老哥侃起了他的职业生涯，既坎坷又无奈，饭后想起来挺有代表性的，征得他同意故记录在此。

以下是老哥的历程。

程序员的前半生

我今年35岁，有房有贷有妻女有老父母。

出生在90年代的农村，从小中规中矩，不惹事不喧哗不突出，三好学生没有我，德智体美没有全面发展。学习也算努力，不算小题做题家，因为只考了个本科。

大学学费全靠助学贷款，勤工俭学补贴日用，埋头苦干成绩也只在年级中等偏下水平。有些同学早早就定下了大学的目标，比如考研、比如出国、比如考公，到了大三的时候大家基本都有了自己的目标。而我的目标就是尽早工作，争取早日还完贷款，因此早早就开始准备找工作。

也许是上天眷顾，不知道怎么就被华为看重了（那会华为还没现在的如日中天，彼时是BAT的天下），稀里糊涂的接受了offer，没想到却是改变了后面十年的决定。

2013年，深圳的夏天阳光明媚，热气扑鼻，提着一个简单的箱子进入了坂田基地。

刚开始，工作上的一切都很新鲜，每个人都在忙碌，虽然不知道他们在忙什么，但感觉很高级的样子。同期入职的同事都比较厉害，很快就适应了工作，而自己还是没完全应对工作内容，于是下班之后继续留在公司学习，顺便蹭饭。

就这样，很快就一年过去了，自己也慢慢熟悉了工作节奏，但是加班也越来越多了。对于自己来说，为了过节点，6点是晚饭时间，9点是下班时间，12点正式下班。

平凡的日子没什么值得留恋，过一天、一个月、一年、四年都没什么两样，四年里学习到了不少的知识，也数了很多次深圳凌晨的路灯数。

作为深漂，没有遇到深圳爱情故事，也对高昂的房价绝望，于是决定回到二线城市，成为一名蓉漂。
2017年，还是和四年前一样的行李箱，出现在了老家的省会城市，只是那时的我没有了助学打款，怀里也攒下了一些血汗钱。

那时互联网行业发展还是如火如荼，前端的需求量也很大，也得益于华为公司发展越来越好，自己的华为经历很快就拿到了几个offer，选了一家初创公司，幻想着能有一番成就。

2018年底，眼看着房价越长越高，某链中介不断地灌输再不买明天就是另一个价了，错过这个村就没这个店了，也许是想有个家，也许是想着父母能到省会里一起住，拿出自己做牛马几年的积蓄加上父母一辈子辛苦攒的小十万的养老钱购买了城区里的新房，那会儿的价格已经比前两年涨了一倍多，妥妥的高位站岗，不过想着自己是刚需也不会卖，因此咬咬牙掏出了全部的积蓄怒而背上了三十年的房贷。

房子的事暂时落定了，全身心的投入到工作中，没想到老板只想骗投资人的钱，产品没弄好投资人不愿跟进了，坚持了三年，期间各种断臂求生，最终还是落了个司破人走的境地。

2020年，30岁的我第一次被动失业了，幸运的是也找到了另一半。为了尽可能节省支出，房子装修的事我们都是亲力亲为，最后花了十多万终于将房子装好了，虽然很简单但毕竟是自己在大城市里的第一套房子，那一刻，感觉十年的付出都是值得的。

背着沉重的房贷，期望能找到一份薪资稍微过得去的工作，于是在简历上优势那行写了：“可加班”。依稀记得有些HR对我进行了灵魂拷问：结婚了吗？有小孩了吗？你都30岁了还能加班吗？。我斩钉截铁地说：只要公司有需要，我定会全力以赴！

2022年，我们的孩子出世了，队友辞去了工作全心全意带小孩，而我更加努力了，毕竟有了四脚吞金兽，不得不肝。

虽然工作很努力，但成果一般，不是公司的技术担当，也不会是技术洼地。

2023年的某一天，和之前的364天一样的平淡，在座位上解Bug的我突然感觉到一阵心悸，呼吸不畅，实在不行了呼唤同事叫了120，去医院一套检查下来没发现什么大问题。医生询问是不是工作压力太大，平时加班很多？我说还好，平时也就加班到9点。医生笑了笑说你这种年轻人我见多了，都是压力大的毛病，平时工作不要久坐盯着屏幕多站起来走走。他让我回家多休息，回去后观察了几天还是偶尔会有心悸，再去了另一个医院进行检查，也是没有明确的诊断结果，只是说可能是这个问题，又可能是另一个问题。

过了1个月后，身体上的问题不见好转，我辞去了工作。

2023年末，找了一家小公司，也就是我现在的公司，工资没有涨，仔细算起来还变相下降了。

还是做的业务需求，也没有领导什么人，管好自己就行，直属上级还是个工作几年的小伙。这家公司主要的特点是不加班，技术难度不高，能做多少就是多少，前提是要报风险，领导也不会强迫加班。

就这样到了2024，神奇的是我已经很久没有心悸的感觉了，不知道是不加班还是心态转变的原因。
家里的小朋友也长大了，会说话了。我现在每天下班最温馨的的是她开着门期待我回家的那一刻，她的期盼的眼神就是我回家的动力。

公司在2024年也裁了不少人，领导也找我谈过问问我的想法，我说：我还是能胜任这份工作的。领导说：公司觉得你年级大了一些，工资虽然不是最高，但不太符合行情，你懂的。我说：我懂，可以接受适当的降薪。
就这样，我挺过了2024，然而过了一周领导走了。

2025年，我35周岁了。
现在的我已经彻底接受自己的平庸的事实了。在学生时代，从来都不出色，也不会垫底，就是那类最容易被忽略的人。在工作时代，不是技术大牛，也不是完全的水货，就是普普通通的程序员。

如果说上半生吃到了什么红利，只能说入坑了计算机这行业，技术给我带了收入，有了糊口的基础。没进股市，却被房价狠狠割了一道。

35岁的我，没有彻底躺平摆烂，也没有足够奋发进取。

35岁的我，有着24年的房贷，还好61岁的时候我还在工作，应该还能还房贷。

35岁的我，不吃海鲜不喝酒，尿酸500+。

35岁的我，人体工学椅也挽救不了腰椎间盘突出。

35岁的我，头发依然浓密，只是白发越来越多。

35岁的我，已经不打游戏，只是会看这各种小说聊以慰藉。

35岁的我，两点一线，每天挤着地铁，看众生百态。

35岁的我，早睡早起，放空自己。

35岁的我，暂时还没有领取毕业大礼包，希望今年还能苟过。

35岁的我，希望经济能够好起来，让如我一般平凡的人能够有活下去的勇气。

诸君，下一年再会~祝你平安喜乐，万事顺遂！

太极分两仪，有程序员也有程序媛：30岁的程序媛，升值加薪与我无缘

为啥要写

最能唬人的前端工种是啥？最能出活的前端模块是啥？跟大家讲，真的是搞动画那一块，搞特效那一块，搞3d、webgl那一块。出活，真的出活。

吭哧吭哧一些高深的框架或者死磕一个难啃的技术硬骨头老半天，给不懂技术的人看，他未必能懂，可能他还会心想：”做老半天，啊？就这...要我来我也会（翻白眼🙄）“。真是这样的。

所以说，唬得住人的，绝b有视觉滚动这一块。

搜一些外国佬的一些产品官网，十个有八个是类似这样的。我们熟悉的苹果官网也是这样的。

再多的，我不举例了。

那身为前端的，切图仔的，小卡拉米的，千千万万个我，绝不能说不会。一般人会看到一个官网有这种视差效果，就会打开给你看，问：”你说你是前端，那你会做这个效果吗“。

这个时候，咱一定得把这个ac中间那个字母给支棱起来。不能丢了面。去搜库搜包，借助工具给它搞出来。

不要说不行

要做这种视觉滚动效果，给jym推荐一个库，啥库呢？gsap

这个玩意，能通过最少的代码实现令人惊叹的滚动动画。

外国佬很多网站，甚至我们国内很多官网，搞这种装ac中间那个字母的官网，离不开这个库。

咋用

写原生，不搞框架的：

就用cdn，引就行了：

<script src="https://cdn.jsdelivr.net/npm/gsap@3.12/dist/gsap.min.js"></script>

引完这个gsap的库的js呢，完呢，再引入一个插件，叫ScrollTrigger，两者一结合，啥滚动动画能做不出来你说，官网都说了:GSAP的ScrollTrigger插件通过最少的代码实现令人惊叹的滚动动画。

<html lang="en">

  // 每个section都有个背景，和一个h1的文字

  <section>

    <h1>111</h1>

  </section>

  <section>

    <h1>222</h1>

  </section>

  <section>

    <h1>333</h1>

  </section>

  

  <body>

    <script src="https://cdn.jsdelivr.net/npm/gsap@3.12/dist/gsap.min.js"></script>

    <script src="https://cdn.jsdelivr.net/npm/gsap@3.12.7/dist/ScrollTrigger.min.js"></script>

  </body>

</html>

上面就把html那一块写完了，接着写js：

const sections = document.querySelectorAll('section'); // 获取页面中所有的<section>元素



sections.forEach(se => {

  // 从初始到目标的动画

  gsap.fromTo(se, {

    backgroundPositionY: `-${window.innerHeight / 2}px`, // 向上偏移（初始背景垂直位置为视口高度一般的负值）

  }, {

    backgroundPositionY: `${window.innerHeight / 2}px`, // 向下偏移（视口高度的一般的正值）

    duration: 3, // 动画持续3s

    ease: 'none', // 线性曲线

  })

})

接下来用到ScrollTrigger插件:

const sections = document.querySelectorAll('section'); // 获取页面中所有的<section>元素



gsap.registerPlugin(ScrollTrigger); // gsap注册插件ScrollTrigger



sections.forEach(se => {

  // 从初始到目标的动画

  gsap.fromTo(se, {

    backgroundPositionY: `-${window.innerHeight / 2}px`, // 向上偏移（初始背景垂直位置为视口高度一般的负值）

  }, {

    backgroundPositionY: `${window.innerHeight / 2}px`, // 向下偏移（视口高度的一般的正值）

    duration: 3, // 动画持续3s

    ease: 'none', // 线性曲线

    scrollTrigger: {

      trigger: se, // 触发的是当前的section

      scrub: true, // 按滚动条去做这个视觉效果

    }

  })

})

总结

好了，如果你觉得神奇，停止往下看，自个儿去官网瞅一眼，别听我在这瞎叨叨，自己去瞅一眼，它啊，不单单是我说的这种视差滚动效果可以做，还有很多动画可以搞，它是一个动画库，我只是说的其一。

动画滴本质实质上就是数字的变动。动来动去就有了动画。这个库帮我们做了很多活，我们拿来用，我们就关注应该怎么变动数字，哪些数字，就完事。前人栽树，后人乘凉，有时候有效地聪明地灵活地有思路地去运用一些库一些包会让事情事半功倍，让效率提升，让时间缩减，让效果更美妙。

特效

往往，玩这些特效的，💰会报得高：

• 视差滚动（Parallax Scrolling）：通过背景层与内容层滚动速度差异营造空间感，适用于官网、营销页等场景，开发成本低但感知价值高。
  
  
  
  • 3D交互（Three.js/WebGL）：如产品展示、虚拟展厅等，结合Canvas或WebGL实现，技术门槛较高但报价可达数万元。
  
  
  • 粒子动画（Particles.js/GSAP）：用于登录页、Loading动画等，开发周期短但视觉效果突出，适合按模块打包报价。
  
  
  • SVG路径动画：适用于图标、数据可视化等场景，通过GreenSock等工具实现，复杂度可控且客户感知专业性强。
  
  
  
  

推荐大家工具，或许对你当前比较恼火的无法着手的特效，可能有思路：GSAP（动画库）、Three.js（3D渲染）、Pixi.js（2D渲染）。

报价策略：优先选择视觉效果显著、开发效率高的特效类型（如视差滚动、3D交互），报价可以溢出点，客户会觉得干了很多活才出这么牛的效果，交付的时候，特别是官网，也不会说太干巴巴，就只是图垒字，字垒图这种。有动画的官网，会使得更多的阅览量，触动更多的购买欲。

我想多些技术传奇，但是为啥总是那么多曲折的世俗故事，这也是别扭极了。

我博客这儿有技术方案，也好多IT行业的狗血故事。盘点了一下，都快成系列短剧了。

再往前，故事更多。而且总是引发着网友的讨论，以及成千上万的关注量。

今天这个故事，讲的是我放弃了大公司，去了小公司的故事。

刚辞职离开的公司，是超过500人的企业，不缺钱，很土豪。再之前的公司也都是几百人的公司，最次也是新三板挂牌。而现在，我却入职了一家不到10个人的小公司。

我没疯。

咋说呢？我从大公司干了十多年，又能怎样呢？无非就是混日子，混工资。但是，随着年龄的增长，这种状态还能维持多久呢？我并不想混一天是一天。

很多朋友说，你怎么不继续去大公司？目前的大环境，大公司稳定，抗风险能力强。

但是，我刚辞职的这家就是挺大的公司，其实也并不“稳定”。

我依然是修炼不够，同时不愿躺平之心游丝尚存。

上一份工作，我以为找到了职业生涯的终极归宿，因为它太契合我了。可以说，它需要我，我也需要它。

我做教育信息化10年了，从手机到平板，从客户端到服务端，从硬件到软件，从团队管理到技术方案，再到后来将人工智能融入教育领域。说实话，即便如此，我想找份称心如意的工作依然不容易。因为，一个行业待久了，技能窗口变得既深又窄。比如试卷的电子化和批阅，我就研究了3年，可以说做到了行业领先。

但是，并没有几家公司需要这类冷门的技能。

同样，公司这边也面临同样的问题：找一个经验丰富的业内人，也很难。

我需要一个平台，让我继续研究教育领域的人工智能，我有信心让他成为行业领先。而公司需要一个员工帮它打造专业领域的业务，它也有能力供给我可观的收入。

因此，我俩一拍即合。

这家公司规模大，资金链充足，福利待遇又好。我一度认为，我的职业生涯终于可以稳定下来了，这是个好平台，我立志干到退休。

但是，我错了。

有一天，突然一个同事找到我，说要跟我谈谈。

这个同事不是行政不是HR，也不是我的领导，工作上和我也没有交集。离下班还有1分钟，给我发钉钉让我下班别走。

我当然不惯着他，我问他什么事情。他回复说，等他写完代码。

我说，我还有事，要去车站接人，请尽快。

他叫我去会议室，他告诉我说，我这个岗位是因为有临时需求才招聘的，现在我把活干完了，他也能接手，我就可有可无了。

我问什么意思，要裁我吗？

他说不是，现在只有他能救我，他一句话，我就能留，另一句话，我就得走。

第一次谈话，就这么结束了。算是一个下马威。

第二天，我去找我的直属领导。我问昨天找我谈话的那个白胖子什么角色，他说的话可不可信。

领导说，一半可信，一半不可信。

可信之处在于他是新来高管老郭身边的红人，老郭对他言听计从。不可信之处是他什么都不懂，一动代码就捅娄子，根本接不了我写的AI项目。

后来，我也见识到白胖子的能力，就是特别自信，他知道fastjson是阿里的开源项目，所以它笃定fastapi也必定是阿里开源的。这一点让老郭非常欣赏，因为白胖子总是有肯定的回答。而其技术只会说：可能……也许……大概……不敢保证……

有一次白胖子专门设计陷害一个老实同事，结果得到了老郭的大力支持。这一举动让其他同事既不满又无奈，更多的是害怕。而白胖子则以此示威，更加自信。

后来，白胖子又找我谈话。

他说他不想找我，但是老郭老问，他不得不找我。

他找我的主要目的是跟我谈我该怎么被安排的问题。他说，我现在很尴尬，原因是我的工作很差。主要体现在负责的项目太少，因为目前我手头就一个从0到1自研AI的项目。

我很震惊，手敲一个从0到1的自研AI项目，而且我只报了1个月的工期，保证保质保量地完成，这还不够炸裂吗？！做完了，就是公司的自主知识产品，可以申请专利的那种！这可是一个大项目，类似的项目，我上家公司投入几十万都没干成，后来我用2个月时间做了出来，当时我还受到了集团董事长的接见。

而在这里，我分析需求做定制开发，居然被谈话，理由是活太少？！

他说，你看看别人：小张，这个月干了5件事：修改A项目首页的弹窗文案，将“你好”改为“您好”；给B项目一个500行代码的类加了35条注释；C项目实现了登录功能，代码提交量为1500行……

你说说，人家手里5个项目，而你1个项目，这是5倍的差距。

我说，郭总也这么看吗？白胖子说，当然，郭总多厉害，肯定知道5大于1，小学生都知道。

那怎么办……我问他。他说，我早就说过了，现在只有我能救你。你要有空，我们先吃个饭聊聊，合适的话，我叫上郭总再一起吃个饭……

我说，如果不合适呢？他说，我现在站在个人角度给你聊，要是站在公司角度……

“公司角度怎么样？”

“现在就可以走流程了！你个人能和法人玩得起吗？”

我说，我再想想。

后来，他又找我。

这次，我留了个心眼，打开了手机录音。他还是哪些话，基本就是打压和威胁，只不过更重了一些。

这次我跟他顶嘴了，我说要谈离职也是人事跟我谈，你既不是人事也不是我领导，你没有资格。

最后不欢而散。

回到座位后，我听到从远处传来郭总的声音：怎么这么过分……那怎么能行……简直是不像话……

次日，我已经不打算在这干了。理由是小白胖子并没有什么可怕的，这种人我见多了。但是你一个集团高管居然受制于他，这就奇葩了。

我就把录音发给了HR总监，面谈了一会儿。总监说，我们了解下情况。

我感觉这类情况很严重，没想到公司会这么对待员工。如果不是公司的意思，那么个人行为更恶劣。

结果，HR将情况告知了郭总，让郭总找我聊聊。

我原来以为只是白胖子的个人想法，因为一个花十几万猎头费聘来的大集团高管，不至于境界那么低，偏听偏信，一点技术上的判断力都没有。但是，后来跟郭总一聊发现，他的想法完全受白胖子影响。换句话说，郭就是个傀儡，他也不了解该如何工作，完全听白胖子的。也就是郭当皇帝拿工资，任命白胖子为常务皇帝干活。

郭说，现实情况就是你可有可无。如果你足够听话，我肯定会保你。如果不听话，那么他只能重新招人。

这还有什么理由待下去呢？我提出了辞职。

一开始，白胖子一派很开心，马上就批准我的辞职。后来，他们开始紧张了起来。

据说，白胖子原计划将我搞走后，引入他的认识一个熟人进来。

但是他的人来面试之后，履历不匹配，还要价太高，远超出我的薪资，公司没有同意。结果，“人傻、钱多、速来”的换人计划落空，我又被搞走了，导致AI项目无人接手了。

现在，他们赶紧启动招人，并且尽量拖着不让我走。

这个公司离职交接很快，这是几十年的传统。你一旦提出离职，不管何种岗位，是否有交接人，三两天必定办完手续走人。

但是，我破纪录了。我被卡了半个多月，愣是不给我办离职手续。一催就说，法律规定30天才能走。

这就矛盾了，前期你说我可有可无，是个可怜虫，现在又不让我走。

后来，我就催。我说没活了，还留我干什么？结果他们给我安排改bug的工作。我的AI项目识别率99%，他们测出那识别不了的1%算bug，让我修改。

改不出来，就不办手续。

搞得我都想留下来了，留下来让你们辞退我得了，还能拿赔偿。
最后，多方运动，终于办完了手续。
就在最后运维、财务、人力全部都签完字了，还是不给离职证明，说要改bug到满意为止。

从业这么多年来，没有经历这么恶心的事情。

最后，总算是走了。

一个月后，发了离职工资，金额不对。我找公司专门负责工资核算的员工，打电话不接，加微信不通过。托其他同事的关系，才要到了工资条。后来，他们居然还想问我工作上的问题。

这就是大公司，以及大公司里的人情世故。

后来，也听到很多同事的吐槽，说公司如何如何。

一入职白胖子就会鼓动新人去请领导吃饭，表示站队。我就是没有站队，导致被针对。

还有，一动代码就捅娄子的白胖子，曾经动过一次代码，结果捅了大篓子。导致集团追责，技术部全体员工都被扣了工资。因为白胖子通过口若悬河的说辞，让自己完全撇清了关系。因此部门领导扣了全体同事的，唯独没扣白胖子的。结果，同事找到了Git代码提交记录，发现完全就白胖子自己一个人的疏忽造成的。这就是“集体闹绩效事件”。但是，即便集体闹，也没什么用。

我最反感的是即便大家都知道此人横行霸道，但是大家依然无能为力。

因为这个公司太大了，管事的人太多了，导致都管不了，也改变不了。现实情况是只有老板能管，但是老板很信任他建立的体系。

如果有人把白胖子的事迹告诉老板，那老板会狠批告密者，这叫打小报告，是严重违纪。因为公司有七八个部门，大约上百人专门做人员的评价工作，他们每天的工作就是进行风气整治和文化的净化。

但是，这些部门都知道白胖子的事迹，就算都觉得不对，谁来下这个手？肯定不是自己！这是得罪用人部门的事情。那就等老板知道了，老板发了话，大家才抢着干。但是老板又不让打小报告，永远不会知道。那就是用人部门说了算。用人部门又听白胖子。

所以，最后的结果就是白胖子没人能管得了。

在一个很大的体系里，最大的成本就是管理成本，也就是让这个体系能运转的成本。得有200人做服务才能支撑另外200人能正常上下班。

我的另一个感觉就是，大公司的反应速度太慢了。

我从0到1做一个同样需求的AI项目，我在10人企业只需要1个月，在100人企业需要3个月，而在这里，可能1年都干不完。因为周边的东西太多了。会有太多的部门卡你，有功都来抢，有锅都来甩。开不完的罗圈会，写不完申请，以及数不清的明枪暗箭。咱们是技术人，不是朝堂上的政治家。

我实在是不愿意浪费时间在这些人身上，我更愿去研究AI，研究教育。

而小公司就不一样了。可以直面老板，可以直面客户，可以直面技术。行动迅速敏捷，效率高。

如今的市场变化很快，需要快速响应，需要快速迭代，需要快速试错。新模式的爆发速度，让人猝不及防。

跟着小公司老板有很多可以学习的地方，会亲历一个想法从诞生到落地，这些我全程都会亲历，这很有可能就是我的以后。

随着年龄的增长，越来越不愿意待在能养老的地方，反而愿意去折腾，去挑战。因为剩下的时间不多了。

目前入职了一家小公司，不用打卡，不用写各种汇报材料，不用请领导吃饭，同事间关系简单，老板有活力，有想法，有干劲。中午吃完饭，会去园区里走走，晒晒太阳，听听鸟叫，高效率工作，大家也经常和老板有那种面红耳赤的讨论，这在集团企业内是不敢想的，更有一种独立人的自主感。我所写的代码，客户、同事和自己都满意，这是我非常喜欢的。

我一直是跟着自己的感觉走，从不委屈自己的内心。我一个老领导生病了，心脑血管方面的问题。术后，医生不让他抽烟喝酒。后来，他轻度抑郁。医生开始让他每周不能超过2顿酒，每天不超过3支烟。他问医生，为什么现在又可以了？医生说，相比于抑郁症，抽烟喝酒的伤害更小一些。心情对人体的影响，胜过肉体的伤害。工作十多年，我几乎都是裸辞。找工作也基本不内推，走网上投简历。每次也都找的挺好，下一家总能解决上一家的问题。当然，新一家也会有新的问题，但每次都是迈上一个新台阶。干这行，能进步就好。

不委屈自己的内心，也不委屈自己的能力。一切都有解决方案，未知的变化胜过已知的不变。

期望我现在的公司越来越好。也祝原来的公司蒸蒸日上。

另外，我相信白胖子以后肯定比我混得好，甚至我相信他去另一家公司依然能混得风生水起，但是这并不影响我坚守我自己内心的信念。

这就是各有各的道。我老领导经常召集众兄弟给他帮忙，我们多数也是友情出演。他经常感慨，自己也狠不下心去干一些坑蒙拐骗的活，即便他知道别人干项目就是“要么坑客户，要么坑自己”，他也依然选择自己吃点亏。不然他也能混的风生水起。但是，也正是因为他这么做，他才能召集起来我们这一众兄弟。我们本就不是耍心机的人，因此才愿意向他靠拢。他要变了，虽然我们也很一般，那他身边该换人了。

都有各自的活法，无所谓好坏之分。

最近投稿了阮一峰周刊 to-unocss 的网站。

这个网站可以直接将 style 转换成 UnoCss 语法, 他内部使用了 transform-to-unocss 的库，可以直接将 SFC 页面转换成 UnoCss SFC，这个特性，它能带来的收益就是，可以将你原本 sass、less、class、inline-style 转换成 UnoCss 然后原子化这样 class 能够最大限度被复用，对于 inline-style 被转换后还能带来性能收益，其他转换后能极大程度上减少打包后 css 体积, 当然 transform-to-unocss 底层还有一个 ]transform-to-unocss-core 的支持，能够将一长串的 style 输入，编译成 UnoCss 语法的输出，他已经用在用户量不错的 figma 插件的 fubukicss-tool 之中，当然处理 UnoCss，我同样做了 Tailwind 的一套，如果你是 UnoCss 新手，你一定要试试这个网站 to-unocss ,如果你是 vscode 用户可以按住 Unot 这个插件，他提供了 vscode hover inline-style 提示转换和整个 SFC page 转换的强大能力

视频演示： http://www.bilibili.com/video/BV1HY…

作者：前端开发爱好者

上班经常摸鱼的小伙伴们要注意了，老板们的监工神器来了！

ChatLog 是一款开源的聊天记录分析工具，能够帮助用户高效解析、可视化和挖掘聊天数据中的关键信息。

它支持从本地数据库文件获取微信、QQ、Telegram 等主流聊天工具的聊天记录，并通过智能分析、数据可视化等功能，帮助用户更好地管理和利用这些数据。

无论是个人社交分析、团队协作优化，还是商业场景的客户对话洞察，ChatLog 都能提供强大的支持。

ChatLog 核心特点

• 智能分析：自动提取聊天记录中的高频词、情感倾向、活跃时段等关键指标，帮助用户快速了解聊天内容的核心信息。


• 多平台支持：兼容微信、QQ、Telegram 等主流聊天工具导出的数据格式，满足不同用户的需求。


• 数据可视化：生成词云、时序活跃图、关系网络图等，直观呈现聊天特征，让复杂的数据一目了然。


• 隐私保护：本地化处理数据，无需上传云端，确保信息安全。用户可以放心使用，无需担心隐私泄露。


• 自动化报告：一键生成分析报告，支持导出 PDF/Excel，便于分享与存档。

如何快速使用

安装 ChatLog

ChatLog 提供了两种方式安装，一种是直接下载预编译版直接安装，另外一种就是下载源码方式安装

• 下载预编译版：https://github.com/sjzar/chatlog/releases


• 命令行安装：

go install github.com/sjzar/chatlog@latest

对于大部分人来说，直接使用 预编译版 就能满足大部分需求，除非你需要做二次开发的可以下载源码本地运行

执行 ChatLog 启动 Terminal UI 界面。

使用 ↑ ↓ 键选择菜单项，按 Enter 确认选择，按 Esc 返回上级菜单，按 Ctrl+C退出程序。

MCP 集成指南

运行 ChatLog，完成数据解密并开启 HTTP 服务

以 ChatWise 使用 MCP SSE 为例，

在 URL 中填写 http://127.0.0.1:5030/sse，并勾选 动执行工具，点击 查看工具 即可检查连接 chatlog 是否正常：

测试功能是否正常：

更多 MCP 集成指南 查看：https://github.com/sjzar/chatlog/blob/main/docs/mcp.md

“牛马”开始慌了？

在日常工作中，微信等工具已成为“牛马”日常沟通的重要工具。

海量的聊天记录中蕴含着大量有价值的信息，却往往难以高效利用。

ChatLog 的出现，无疑为“牛马”提供了一个强大的工具，可以更高效地管理和分析微信聊天记录。

老板会不会用这个工具来分析我们的聊天记录？

随着 ChatLog 这样的工具出现，不少 “牛马” 开始担心：

老板会不会用这个工具来分析我们的聊天记录？以后摸鱼的时间是不是都没了？

但实际上，ChatLog 的出现更多是为了帮助我们更好地管理自己的聊天记录，提高工作效率。

它可以帮助我们快速总结群聊内容，提取聊天记录中有用的信息，从而更好地完成工作任务。

例如：

• 快速查找聊天内容：通过关键词搜索，快速定位到重要的聊天记录。


• 每周工作总结：自动生成聊天记录的总结报告，帮助我们快速回顾本周的工作重点。


• 提取关键信息：从大量聊天记录中提取关键信息，比如客户的需求、项目进展等，方便我们进行后续的工作安排。

总之，ChatLog 是一款功能强大的开源聊天记录分析工具。

它不仅支持多种主流聊天工具的数据格式，还提供了智能分析、数据可视化和自动化报告生成等功能。

• ChatLog Github 地址：https://github.com/sjzar/chatlog

最近正在忙着准备AI产品示例项目的数据，但是有好几群友问了MCP的问题，先花点时间给大家安排一下MCP。作为一个带队落地AI应用的真实玩家，是怎么看待MCP的。

先说观点：MCP不错，但它仅仅是个协议而已，很多科普文章中，提到的更多都是愿景，而不是落地的场景。

本文不再重新陈述MCP的基本概念，而是旨在能让大家了解的是MCP 有什么用？、怎么用？、要不要用？

我准备了一份MCP实现的核心代码，只保留必要的内容，五分钟就能看明白MCP回事。

先上代码，让我们看看实现MCP最核心的部分我们都干了些什么东西。顺便让大家看看MCP到底和Function call是个什么关系

此处只贴用于讲解的代码，其他代码基本都是逻辑处理与调用。也可关注公众号：【华洛AI转型纪实】，发送mcpdemo，来获取完整代码。

MCP代码核心逻辑

我们在本地运行的MCP，所以使用的是Stdio模式的客户端和服务端。也就是：StdioServerTransport和StdioClientTransport

先看打满日志的demo运行起来起来后，我们获得的信息：

我们的服务端写了两个简单的工具，加法和减法。

服务端启动成功之后，客户端成功的从服务端获取到了这两个工具。

我们发起了一个问题：计算1+1

接下来做的事情就是MCP的客户端核心三步逻辑：

我们一边看代码一边说里面的问题：

第一步调用AI，决定使用工具

客户端代码：

  const response = await this.openai.chat.completions.create({

    model: model,

    messages,

    tools: this.tools, // ! 重点看这里，this.tools是服务端返回的工具列表

  });

看到了么？这里用的还是Function call! 谣言一：MCP和Function call没关系，MCP就可以让大家调用工具，终结了。MCP就是用的function call的能力来实现的工具调用。当然我们也可以不用Function call，我们就直接用提示词判断，也是可以的。

这里要说的是：MCP就是个协议。并没有给大模型带来任何新的能力，也没有某些人说的MCP提升了Function call的能力，以后不用Function call了，用MCP就够了这种话，千万不要被误导。

MCP并没有让大模型的工具调用能力提升

在真实的生产环境中，目前Function call主要的问题有：

• 工具调用准确性不够。
  真正的生成环境可能不是三个五个工具，而是三十个五十个。工具之间的界限不够清晰的话，就会存在模型判断不准确的情况。


• 参数提取准确性不够。
  特别是当一个工具必填加选填的参数达到十个以上的时候，面对复杂问题，参数的提取准确率会下降。


• 多意图的识别。
  
  用户的一个问题涉及到多个工具时，目前没有能够稳定提取的模型。

第二步把工具和参数发回服务端，由服务端调用API

客户端代码：

const result = await this.mcp.callTool({

  name: toolName,

  arguments: toolArgs,

});

服务端的代码：

server.tool(

  "加法",

  "计算数字相加",

  {

    "a": z.number().describe("加法的第一个数字"),

    "b": z.number().describe("加法的第二个数字"),

  },

  async ({ a, b, c }) => {

    console.error(`服务端: 收到加法API，计算${a}和${b}两个数的和。模型API发送`) 

    // 这里模拟API的发送和使用

    let data = a + b

    return {

      content: [

        {

          type: "text",

          text: a + '+' + b + '的结果是：' + data,

        },

      ],

    };

  },

);

发现问题了么？ API是要有MCP服务器提供者调用的。要花钱的朋友！

每一台MCP服务器背后都是要成本的，收费产品进行MCP服务器的支持还说的过去，不收费的产品全靠爱发电。更不要说，谁敢在生成环境接一个不收费的私人的小服务器？

百度地图核心API全面兼容MCP了，百度地图是收费的，进行多场景的支持是很正常的行为。

来看看百炼吧，阿里的百炼目前推出了MCP的功能，支持在百炼上部署MCP server。

也是要花钱的朋友~，三方API调用费用另算。

阿里的魔塔社区提供了大量的MCP，可以看到有一些大厂的服务在，当然有收费的有免费的，各位可以尝试

第三步客户端根据结果，再次调用AI，由AI进行回答。

客户端代码：

messages.push({

  role: "user",

  content: result.content,

});



const aiResponse = await this.openai.chat.completions.create({

  model: model,

  messages: messages,

});

从服务端返回的结果，添加到messages中，配合提示词由大模型进行回复即可。

这一步属于正常的流程，没什么好说的。

那么问题是：我们使用MCP来实现，和我们自己实现这套流程有什么区别么？我们为什么要用MCP呢？

当初群里朋友第一次提到MCP的时候，我去看了一眼文档，给了这样的结论：

大厂为了抢生态做的事情，给落地的流程中定义了一些概念，多了脑力负担，流程和自己实现没区别。

对于工具的使用，自己实现和用MCP实现有什么区别么？

自己实现的流程和逻辑是这样的：

MCP的逻辑是这样的：

看吧，本质上是没有区别的。

什么？你说MCP服务端，如果日后需要与其他企业进行合作，可以方便的让对方的MCP客户端调用？
我们的客户端也可以很方便的接入别人的MCP服务端。

不好意思，不用MCP也可以，因为Function call的参数格式已经确定了，这里原本存在差异性就极小。而且MCP也并没有解决这个差异性。还是需要客户端进行修改的。

MCP真正的意义

现在还是诸神混战时期，整个AI产品的上下游所有的点，都具有极高的不确定性。

MCP给出了一个技术标准化的协议，是大家共建AI的愿景中的一环，潜力是有的。

但是Anthropic真的只是在乎这个协议么？前面的内容我们也看到了，MCP和我们自己实现的流程几乎是一样的。但是为什么还要提出MCP呢？

为了生态控制权和行业话语权。

MCP它表面上是一个开放的协议，旨在解决AI模型与外部工具集成的碎片化问题，但其实他就是Anthropic对未来AI生态主导权的竞争。

未来MCP如果真的作为一个标准的协议成为大家的共识，围绕这个协议，甚至每家模型的工具调用格式都将被统一，此时Anthropic在委员会里的位置呢？不言而喻啊。

结语

最后把我的策略分享给大家吧：

打算在圈子里玩的部分，就和大家用一样的，不在圈子里玩的，其实自己团队实现也是OK的。

我这边更多的是自己团队实现的，而且在这个实现过程中大家对模型应用、AI产品的理解不断地在提升。

希望各位读者也多进行尝试，这样未来面对新出的各路牛鬼蛇神时大家才能有更多的判断力。

共勉吧！

☺️你好，我是华洛，如果你对程序员转型AI产品负责人感兴趣，请给我点个赞。

你可以在这里联系我👉http://www.yuque.com/hualuo-fztn…

已入驻公众号【华洛AI转型纪实】，欢迎大家围观，后续会分享大量最近三年来的经验和踩过的坑。

实战专栏

# 从0到1打造企业级AI售前机器人——实战指南一：根据产品需求和定位进行agent流程设计🧐

# 从0到1打造企业级AI售前机器人——实战指南二：RAG工程落地之数据处理篇🧐

# 实战派！百万PV的AI产品如何搭建RAG系统？

# 团队落地AI产品的全流程

# 30行代码，随时进行云端大模型能力评估！

# 5000字长文，AI时代下程序员的巨大优势！

2025 年可以说又是一个跨平台的元年，其中不妨有「鸿蒙 Next」 平台刺激的原因，也有大厂技术积累“达到瓶颈”的可能，又或者“开猿截流、降本增笑”的趋势的影响，2025 年上半年确实让跨平台框架又成为最活跃的时刻，例如：

• Flutter Platform 和 UI 线程合并和Android Impeller 稳定


• React Native 优化 Skia 和发布全新 WebGPU 支持


• Compose Multiplatform iOS 稳定版发布，客户端全平台稳定


• 腾讯 Kotlin 跨平台框架 Kuikly 正式开源


• 字节跨平台框架 Lynx 正式开源


• uni-app x 跨平台框架正式支持鸿蒙


• ····

而本篇也是基于上面的内容，对比当前它们的情况和未来可能，帮助你在选择框架时更好理解它们的特点和差异。

就算你不用，也许面试的时候就糊弄上了？

Flutter

首先 Flutter 大家应该已经很熟悉了，作为在「自绘领域」坚持了这么多年的跨平台框架，相信也不需要再过多的介绍，因为是「自绘」和 「AOT 模式」，让 Flutter 在「平台统一性」和「性能」上都有不错的表现。

开发过程过程中的 hotload 的支持程度也很不错。

而自 2025 以来的一些更新也给 Flutter 带来了新的可能，比如 Flutter Platform 和 UI 线程合并 ，简单来说就是以前 Dart main Thread 和 Platform UI Thread 是分别跑在独立线程，它们的就交互和数据都需要经过 Channel 。

而合并之后，Dart main 和 Platform UI 在 Engine 启动完成后会合并到一个线程，此时 Dart 和平台原生语言就支持通过同步的方式去进行调用，也为 Dart 和 Kotlin/Java，Swift/OC 直接同步互操作在 Framework 提供了进一步基础支持。

当然也带来一些新的问题，具体可见线程合并的相关文章。

另外在当下，其实 Flutter 的核心竞争力是 Impeller ，因为跨平台框架不是系统“亲儿子”，又是自绘方案，那么在性能优化上，特别 iOS 平台，就不得不提到着色器预热或者提前编译。

传统 Skia 需要把「绘制命令」编译成可在 GPU 执行代码的过程，一般叫做着色器编译， Skia 需要「动态编译」着色器，但是 Skia 的着色器「生成/编译」与「帧工作」是按顺序处理，如果这时候着色器编译速度不够快，就可能会出现掉帧（Jank）的情况，这个我们也常叫做「着色器卡顿」

而 Impeller 正是这个背景的产物，简单说，App 所需的所有着色器都在 Flutter 引擎构建时进行离线编译，而不是在应用运行时编译。

这其实才是目前是 Flutter 的核心竞争力，不同于 Skia 需要考虑多场景和平台通用性，需要支持各种灵活的额着色器场景，Impeller 专注于 Flutter ，所以它可以提供更好的专注支持和问题修复，更多可见：着色器预热？为什么 Flutter 需要？

当然 Skia 也是 Google 项目，对于着色器场景也有 Graphite 后端在推进支持，它也在内部也是基于 Impeller 为原型去做的改进，所以未来 Skia 也可以支持部分场景的提前编译。

而在鸿蒙平台，华为针对 Flutter 在鸿蒙的适配，在华为官方过去的分享里，也支持了 Flutter引擎Impeller鸿蒙化，详细可见：b23.tv/KKNDAQB

甚至，Flutter 在类游戏场景支持也挺不错，如果配合 rive 的状态机和自适应，甚至可以开发出很多出乎意料的效果，而官方也有 Flutter 的游戏 SDK 或者 Flame 第三方游戏包支持：

最后，那么 Flutter 的局限性是什么呢？其实也挺多的，例如：

• 文字排版能力不如原生


• PC平台推进交给了 Canonical 团队负责，虽然有多窗口雏形，但是推进慢


• 不支持官方热更新，shorebird 国内稳定性一般


• 内存占用基本最高


• Web 只支持 wasm 路线


• 鸿蒙版本落后主版本太多


• 不支持小程序，虽然有第三方实现，但是力度不大


• ····

所以，Flutter 适合你的场景吗？

React Native

如果你很久没了解过 RN ，那么 2025 年的 RN 会超乎你的想象，可以说 Skia 和 WebGPU 给了它更多的可能。

RN 的核心之一就是对齐 Web 开发体验，其中最重要的就是 0.76 之后 New Architecture 成了默认框架，例如 Fabric, TurboModules, JSI 等能力解决了各种历史遗留的性能瓶颈，比如：

• JSI 让 RN 可以切换 JS 引擎，比如 Chakra、v8、Hermes ，同时允许 JS 和 Native 线程之间的同步相互执行


• 全新的 Fabric 取代了原本的 UI Manager，支持 React 的并发渲染能力，特别是现在的新架构支持 React 18 及更高版本中提供的并发渲染功能，对齐 React 最新版本，比如 Suspense & Transitions：


• Hermes JS 引擎预编译的优化字节码，优化 GC 实现等


• TurboModules 按需加载插件


• ····

另外现在新版 RN 也支持热重载，同时可以更快对齐新 React 特性，例如 React 19 的 Actions、改进的异步处理等 。

而另一个支持就是 RN 在 Skia 和 WebGPU 的探索和支持，使用 Skia 和 WebGPU 不是说 RN 想要变成自绘，而是在比如「动画」和「图像处理」等场景增加了强力补充，比如：

React Native Skia Video 模块，实现了原生纹理（iOS Metal, Android OpenGL）到 React Native Skia 的直接传输，优化了内存和渲染速度，可以被用于视频帧提取、集成和导出等，生态中还有 React Native Vision Camera 和 React Native Video (v7) 等支持 Skia 的模块：

还有是 React Native 开始引入 WebGPU 支持，其效果将确保与 Web 端的 WebGPU API 完全一致，允许开发者直接复制代码示例的同时，实现与 Web Canvas API 对称的 RN Canvas API：

最后，WebGPU 的引入还可以让 React Native 开发者能够利用 ThreeJS 生态，直接引入已有的 3D 库，这让 React Native 的能力进一步对齐了 Web ：

最后，RN 也是有华为推进的鸿蒙适配，会采用 XComponent 对接到 ArkUI 的后端接口进行渲染，详细可见：鸿蒙版 React Native 正式开源 。

而在 PC 领域 RN 也有一定支持，比如微软提供的 windows 和 macOS 支持，社区提供的 web 和 Linux 支持，只是占有并不高，一般忽略。

而在小程序领域，有京东的 Taro 这样的大厂开源支持，整体在平台兼容上还算不错。

当然，RN 最大的优势还在于成熟的 code-push 热更新支持。

那么使用 RN 有什么局限性呢？最直观的肯定是平台 UI 的一致性和样式约束，这个是 OEM 框架的场景局限，而对于其他的，目前存在：

• 第三方库在新旧框架支持上的风险


• RN 版本升级风险，这个相信大家深有体会


• 平台 API 兼容复杂度较高


• 0.77 之后才支持 Google Play 的 16 KB 要求


• 可用性集中在 Android 和 iOS ，鸿蒙适配和维度成本更高


• 小程序能力支持和客户端存在一定割裂


• ····

事实上， RN 是 Cordova 之后我接触的第一个真正意义上的跨平台框架，从我知道它到现在应该有十年了，那么你会因为它的新架构和 WebGPU 能力而选择 RN 么？

更多可见：

• React Native 前瞻式重大更新 Skia & WebGPU


• React Native 0.76，New Architecture 将成为默认模式

Compose Multiplatform

Compose Multiplatform（CMP） 近期的热度应该来自 Compose Multiplatform iOS 稳定版发布 ，作为第二个使用 Skia 的自绘框架，除了 Web 还在推进之外， CMP 基本完成了它的跨平台稳定之路。

Compose Multiplatform（CMP） 是 UI，Kotlin Multiplatform (KMP) 是语言基础。

CMP 使用 Skia 绘制 UI ，甚至在 Android 上它和传统 View 体系的 UI 也不在一个渲染树，并且 CMP 通过 Skiko (Skia for Kotlin) 这套 Kotlin 绑定库，进而抹平了不同架构（Kotlin Native，Kotlin JVM ，Kotlin JS，Kotlin wasm）调用 skia 的差异。

所以 CMP 的优势也来自于此，它可以通过 skia 做到不同平台的 UI 一致性，并且在 Android 依赖于系统 skia ，所以它的 apk 体积也相对较小，而在 PC 平台得益于 JVM 的成熟度，CMP 目前也做到了一定的可用程度。

其中和 Android JVM 模式不同的是，Kotlin 在 iOS 平台使用的是 Kotlin/Native ，Kotlin/Native 是 KMP 在 iOS 支持的关键能力，它负责将 Kotlin 代码直接编译为目标平台的机器码或 LLVM 中间表示 (IR)，最终为 iOS 生成一个标准 .framework ，这也是为什么 Compose iOS 能实现接近原生的性能。

实现鸿蒙支持目前主流方式也是 Kotlin/Native ，不得不说 Kotlin 最强大的核心价值不是它的语法糖，而是它的编译器，当然也有使用 Kotlin/JS 适配鸿蒙的方案。

所以 CMP 最大的优势其实是 Kotlin ，Kotlin 的编译器很强大，支持各种编译过程和产物，可以让 KMP 能够灵活适配到各种平台，并且 Kotlin 语法的优势也让使用它的开发者忠诚度很高。

不过遗憾的是，目前 CMP 鸿蒙平台的适配上都不是 Jetbrains 提供的方案，华为暂时也没有 CMP 的适配计划，目前已知的 CMP/KMP 适配基本是大厂自己倒腾的方案，有基于 KN 的 llvm 方案，也有基于 Kotlin/JS 的低成本方案，只是大家的路线也各不相同。

在小程序领域同样如此。

另外现在 CMP 开发模式下的 hot reload 已经可以使用 ，不过暂时只支持 desktop，原理大概是只支持 jvm 模式。

而在社区上，klibs.io 的发布也补全了 Compose Multiplatform 在跨平台最后一步，这也是 Compose iOS 能正式发布的另外一个原因：

那么聊到这里，CMP 面临的局限性也很明显：

• 鸿蒙适配成本略高，没有官方支持，低成本可能会选择 Kotlin/JS，为了性能的高成本可能会考虑 KN，但是 KN 在 iOS 和鸿蒙的 llvm 版本同步适配也是一个需要衡量的成本


• 小程序领域需要第三方支持


• iOS 平台可能面临的着色器等问题暂无方案，也许未来等待 Skia 的 Graphite 后端


• 在 Android JVM 模式和 iOS 的 KN 模式下，第三方包适配的难度略高


• hotload 暂时只支持 PC


• 桌面内存占用问题-


• 没有官方热更新条件


• kjs、kn、kjvm、kwasm 之间的第三方包兼容支持问题


• ····

相信 2025 年开始，CMP 会是 Android 原生开发者在跨平台的首选之一，毕竟 Kotlin 生态不需要额外学习 Dart 或者 JS 体系，那么你会选择 CMP 吗？

Kuikly

Kuikly 其实也算是 KMP 体系的跨平台框架，只是腾讯在做它的时候还没 CMP ，所以一开始 Kuikly 是通过 KMM 进行实现，而后在 UI 层通过自己的方案完成跨平台。

这其实就是 Kuikly 和 CMP 最大的不同，底层都是 KMP 方案，但是在绘制上 Kuikly 采用的是类 RN 的方式，目前 Kuikly 主要是在 KMP 的基础上实现的自研 DSL 来构建 UI ，比如 iOS 平台的 UI 能力就是 UIkit ，而大家更熟悉的 Compose 支持，目前还处于开发过程中：

SwiftUI 和 Compose 无法直接和 Kuikly 一起使用，但是 Kuikly 可以在 DSL 语法和 UI 组件属性对齐两者的写法，变成一个类 Compose 和 SwiftUI 的 UI 框架，也就是 Compose DSL 大概就是让 Kuikly 更像 Compose ，而不是直接适配 Compose 。

那么，Kuikly 和 RN 之间又什么区别?

第一，Kuikly 支持 Kotlin/JS 和 Kotlin/Native 两种模式，也就是它可以支持性能很高的 Native 模式

第二，Kuikly 实现了自己的一套「薄原生层」，Kuikly 使用“非常薄”的原生层，该原生层只暴露最基本和无逻辑的 UI 组件（原子组件），也就是 Kuikly 在 UI 上只用了最基本的原生层 UI ，真正的 UI 逻辑主要在共享的 Kotlin 代码来实现：

通过将 UI 逻辑抽象到共享的 Kotlin 层，减少平台特定 UI 差异或行为差异的可能性，「薄原生层」充当一致的渲染目标，确保 Kotlin 定义的 UI 元素在所有平台上都以类似的方式显示。

也就是说，Kuikly 虽然会依赖原生平台的控件，但是大部分控件的实现都已经被「提升」到 Kuikly 自己的 Kotlin 共享层，目前 Kuikly 实现了 60% UI 组件的纯 Kotlin 组合封装实现，不需要 Native 提供原子控件 。

另外 Kuikly 表示后续会支持全平台小程序，这也是优势之一。

最后，Kuikly 还在动态化热更新场景， 可以和自己腾讯的热更新管理平台无缝集成，这也是优势之一。

那么 Kuikly 存在什么局限性？首先就是动态化场景只支持 Kotlin/JS，而可动态化类型部分：

• 不可直接依赖平台能力


• 不可使用多线程和协程


• 不可依赖内置部分

其他的还有：

• UI 不是 CMP ，使用的是类 RN 方式，所谓需要稍微额外理解成本


• 不支持 PC 平台


• 基于原生 OEM，虽然有原子控件，但是还是存在部分不一致情况


• 在原有 App 集成 Kuikly ，只能把它简单当作如系统 webview 的概念来使用

另外，腾讯还有另外一个基于 CMP 切适配鸿蒙的跨平台框架，只是何时开源还尚不明确

那么，你会为了小程序和鸿蒙而选择 Kuikly 吗？

更多可见：腾讯 Kuikly 正式开源

Lynx

如果说 Kuikly 是一个面向客户端的全平台框架，那么 Lynx 就是一个完全面向 Web 前端的跨平台全家桶。

目前 Lynx 开源的首个支持框架就是基于 React 的 ReactLynx，当然官方也表示Lynx 并不局限于 React，所以不排除后续还有 VueLynx 等其他框架支持，而 Lynx 作为核心引擎支持，其实并不绑定任何特定前端框架，只是当前你能用的暂时只有 ReactLynx ：

而在实现上，源代码中的标签，会在运行时被 Lynx 引擎解析，翻译成用于渲染的 Element，嵌套的 Element 会组成的一棵树，从而构建出UI界面：

所以从这里看，初步开源的 Lynx 是一个类 RN 框架，不过从官方的介绍“选择在移动和桌面端达到像素级一致的自渲染” ，可以看出来宣传中可以切换到自渲染，虽然暂时还没看到。

而对于 Lynx 主要的技术特点在于：

• 「双线程架构」，思路类似 react-native-reanimated ，JavaScript 代码会在「主线程」和「后台线程」两个线程上同时运行，并且两个线程使用了不同的 JavaScript 引擎作为其运行时：


• 另外特点就是 PrimJS ，一个基于 QuickJS 深度定制和优化的 JavaScript 引擎，主要有模板解释器（利用栈缓存和寄存器优化）、与 Lynx 对象模型高效集成的对象模型（减少数据通信开销）、垃圾回收机制（非 QuickJS 的引用计数 RC，以提升性能和内存分析能力）、完整实现了 Chrome DevTools Protocol (CDP) 以支持 Chrome 调试器等


• “Embedder API” 支持直接与原生 API 交互 ，提供多平台支持

所以从 Lynx 的宏观目标来看，它即支持类 RN 实现，又有自绘计划，同时除了 React 模式，后期还适配 Vue、Svelte 等框架，可以说是完全针对 Web 开发而存在的跨平台架构。

另外支持平台也足够，Android、iOS、鸿蒙、Web、PC、小程序都在支持列表里。

最后，Lynx 对“即时首帧渲染 (IFR)”和“丝滑流畅”交互体验有先天优势，开发双线程模型及主线程脚本 (MTS) 让 Lynx 的启动和第一帧渲染速度还挺不错，比如：

• Lynx 主线程负责处理直接处理屏幕像素渲染的任务，包括：执行主线程脚本、处理布局和渲染图形等等，比如负责渲染初始界面和应用后续的 UI 更新，让用户能尽快看到第一屏内容


• Lynx 的后台线程会运行完整的 React 运行时，处理的任务不直接影响屏幕像素的显示，包括在后台运行的脚本和任务(生命周期和其他副作用)，它们与主线程分开运行，这样可以让主线程专注于处理用户交互和渲染，从而提升整体性能

而在多平台上，Lynx 是自主开发的渲染后端支持 Windows、tvOS、MacOS 和 HarmonyOS ，但是不确实是否支持 Linux：

那 Lynx 有什么局限性？首先肯定是它非常年轻，虽然它的饼很大，但是对应社区、生态系统、第三方库等都还需要时间成长。

所以官方也建议 Lynx 最初可能更适合作为模块嵌入到现有的原生应用中，用于构建特定视图或功能，而非从零开始构建一个完整的独立应用 。

其次就是对 Web 前端开发友好，对客户端而言学习成本较高，并且按照目前的开源情况，除了 Android、iOS 和 Web 的类 RN 实现外，其他平台的支持和自绘能力尚不明确：

最后，Lynx 的开发环境最好选 macOS，关于 Windows 和 Linux 平台目前工具链兼容性还需要打磨。

那么，总结下来，Lynx 应该会是前端开发的菜，那你觉得 Lynx 是你的选择么？

更多可见：字节跨平台框架 Lynx 开源

uni-app x

说到 uni-app 大家第一印象肯定还是小程序，而虽然 uni-app 也可以打包客户端 app，甚至有基于 weex 的 nvue 支持，但是其效果只能说是“一言难尽”，而这里要聊的 uni-app x ，其实就是 DCloud 在跨平台这两年的新尝试。

具体来说，就是 uni-app 不再是运行在 jscore 的跨平台框架，它是“基于 Web 技术栈开发，运行时编译为原生代码”的模式，相信这种模式大家应该也不陌生了，简单说就是：js（uts） 代码在打包时会直接编译成原生代码：

甚至极端一点说，uni-app x 可以不需要单独写插件去调用平台 API，你可以直接在 uts 代码里引用平台原生 API ，因为你的代码本质上也是会被编译成原生代码，所以 uts ≈ native code ，只是使用时需要配置上对应的条件编译(如 APP-ANDROID、APP-IOS )支持：

import Context from "android.content.Context";

import BatteryManager from "android.os.BatteryManager";

•

import { GetBatteryInfo, GetBatteryInfoOptions, GetBatteryInfoSuccess, GetBatteryInfoResult, GetBatteryInfoSync } from '../interface.uts'

import IntentFilter from 'android.content.IntentFilter';

import Intent from 'android.content.Intent';

•

import { GetBatteryInfoFailImpl } from '../unierror';

•

/**

 * 获取电量

 */

export const getBatteryInfo : GetBatteryInfo = function (options : GetBatteryInfoOptions) {

  const context = UTSAndroid.getAppContext();

  if (context != null) {

    const manager = context.getSystemService(

      Context.BATTERY_SERVICE

    ) as BatteryManager;

    const level = manager.getIntProperty(

      BatteryManager.BATTERY_PROPERTY_CAPACITY

    );

•

    let ifilter = new IntentFilter(Intent.ACTION_BATTERY_CHANGED);

    let batteryStatus = context.registerReceiver(null, ifilter);

    let status = batteryStatus?.getIntExtra(BatteryManager.EXTRA_STATUS, -1);

    let isCharging = status == BatteryManager.BATTERY_STATUS_CHARGING || status == BatteryManager.BATTERY_STATUS_FULL;

•

    const res : GetBatteryInfoSuccess = {

      errMsg: 'getBatteryInfo:ok',

      level,

      isCharging: isCharging

    }

    options.success?.(res)

    options.complete?.(res)

  } else {

    let res = new GetBatteryInfoFailImpl(1001);

    options.fail?.(res)

    options.complete?.(res)

  }

}

•

​

比如上方代码，通过 import BatteryManager from "android.os.BatteryManager" 可以直接导入使用 Android 的 BatteryManager 对象。

可以看到，在 uni-app x 你是可以“代码混写”的，所以与传统的 uni-app 不同，uni-app 依赖于定制 TypeScript 的 uts 和 uvue 编译器：

• uts 和 ts 有相同的语法规范，并支持绝大部分 ES6 API ，在编译时会把内置的如Array、Date、JSON、Map、Math、String 等内置对象转为 Kotlin、Swift、ArkTS 的对象等，所以也不需要有 uts 之类的虚拟机，另外 uts 编译器在处理特定平台时，还会调用相应平台的原生编译器，例如 Kotlin 编译器和 Swift 编译器


• uvue 编译器基于 Vite 构建，并对它进行了扩展，大部分特性（如条件编译）和配置项（如环境变量）与 uni-app 的 Vue3 编译器保持一致，并且支持 less、sass、ccss 等 CSS 预处理器，例如 uvue 的核心会将开发者使用 Vue 语法和 CSS 编写的页面，编译并渲染为 ArkUI

而在 UI 上，目前除了编译为 ArkUI 之外，Android 和 iOS 其实都是编译成原生体系，目前看在 Android 应该是编译为传统 View 体系而不是 Compose ，而在 iOS 应该也是 UIKit ，按照官方的说法，就是性能和原生相当。

所以从这点看，uni-app x 是一个类 RN 的编译时框架，所以，它的局限性问题也很明显，因为它的优势在于编译器转译得到原生性能，但是它的劣势也是在于转译：

• 不同平台翻译成本较高，并不支持完整的语言，阉割是必须的，API 必然需要为了转译器而做删减，翻译后的细节对齐于优化会是最大的挑战


• iOS 平台还有一些骚操作，保留了可选 js 老模式和新 swift 模式，核心是因为插件生态，官方表示 js 模式可以大幅降低插件生态的建设难度， 插件作者只需要特殊适配 Android 版本，在iOS和Web端仍使用 ts/js 库，可以快速把 uni-app/web 的生态迁移到 uni-app x


• 生态支持割裂，uni-app 和 uni-app x 插件并不通用


• 不支持 PC


• HBuilderX IDE


• ·····

那么，你觉得 uni-app x 会是你跨平台选择之一么？

更多可见：uni-app x 正式支持鸿蒙

最后

最后，我们简单做个总结：

什么，你居然看完了？事实上我写完都懒得查错别字了，因为真的太长了。

前端何时能出个"秦始皇"一统天下？我是真学不动啦！

引言

前端开发的世界，就像历史上的战国时期一样，各种框架、库、工具层出不穷，形成了一个百花齐放但也令人眼花缭乱的局面。

而且就因为百家争鸣，导致各种鄙视链出现

比如 React 和 Vue 互喷

v：你react 这么难用，不如我vue 简单

r：你一点都不灵活，我想咋用咋用

v：你useEffect 心智负担太重，一点都好用

r：啥心智负担，那是你太笨了，我就喜欢这种什么都掌握在自己手里的感觉

v：你内部更是混乱，一个状态管理就那么多种 啥redux、mobx、recoil。。。。不像我们一个pinia 走天下

r：你管我 我想用哪个用哪个，你还说我，你内部对一个 用ref还是用reactive 都吵得不可开交！

......

1. 框架之争

• React: 由Facebook维护的一个用于构建用户界面的JavaScript库。其设计理念是通过组件化的方式简化复杂的UI开发。
  
  
  
  
  • 官网: reactjs.org/
  
  
  • GitHub: github.com/facebook/re…
  
  
  • GitHub Stars: 超过235k（截至2025年4月）
  
  
  
  


• Vue.js: 一种渐进式JavaScript框架，非常适合用来构建单页应用。Vue的核心库只关注视图层，易于上手。
  
  
  
  
  • 官网: vuejs.org/
  
  
  • GitHub: github.com/vuejs/vue
  
  
  • GitHub Stars: 约209k（截至2025年4月）
  
  
  
  


• Angular: Google支持的一个开源Web应用框架，适用于大型企业级项目。它提供了一个全面的解决方案来创建动态Web应用程序。
  
  
  
  
  • 官网: angular.io/
  
  
  • GitHub: github.com/angular/ang…
  
  
  • GitHub Stars: 大约97.5k（截至2025年4月）
  
  
  
  


• Solid.js: 一个专注于性能和简单性的声明式UI库，采用细粒度的响应式系统，提供了极高的运行效率。
  
  
  
  
  • 官网: http://www.solidjs.com/
  
  
  • GitHub: github.com/solidjs/sol…
  
  
  • GitHub Stars: 约33.3k（截至2025年4月）
  
  
  
  


• Svelte: 一种新兴的前端框架，通过在编译时将组件转换为高效的原生代码，从而避免了运行时开销。
  
  
  
  
  • 官网: svelte.dev/
  
  
  • GitHub: github.com/sveltejs/sv…
  
  
  • GitHub Stars: 约82.3k（截至2025年4月）
  
  
  
  


• Ember.js: 一个旨在帮助开发者构建可扩展的Web应用的框架，尤其适合大型团队协作。
  
  
  
  
  • 官网: emberjs.com/
  
  
  • GitHub: github.com/emberjs/emb…
  
  
  • GitHub Stars: 约22.6k（截至2025年4月）
  
  
  
  

2. 样式处理满花齐放

样式处理方面可以进一步细分，包括CSS预处理器、CSS-in-JS、Utility-First CSS框架以及CSS Modules等。

• CSS预处理器
  
  
  
  
  • Sass: 提供变量、嵌套规则等高级功能，极大地提高了CSS代码的可维护性。
    
    
    
    • 官网: sass-lang.com/
    
    
    • GitHub: github.com/sass/sass
    
    
    • GitHub Stars: 约15.2k（截至2025年4月）
    
    
    
    
  
  
  • Less: 另一种流行的CSS预处理器，支持类似的功能但语法稍有不同。
    
    
    
    • 官网: lesscss.org/
    
    
    • GitHub: github.com/less/less.j…
    
    
    • GitHub Stars: 约17k（截至2025年4月）
    
    
    
    
  
  
  • Stylus: 一款灵活且功能强大的CSS预处理器，允许省略括号和分号等符号，使代码更加简洁。
    
    
    
    • 官网: stylus-lang.com/
    
    
    • GitHub: github.com/stylus/styl…
    
    
    • GitHub Stars: 约11.2k（截至2025年4月）
    
    
    
    
  
  
  
  


• CSS-in-JS
  
  
  
  
  • styled-components: 允许你通过JavaScript编写CSS，并将样式直接附加到组件上。
    
    
    
    • 官网: styled-components.com/
    
    
    • GitHub: github.com/styled-comp…
    
    
    • GitHub Stars: 约40.8k（截至2025年4月）
    
    
    
    
  
  
  • Emotion: 类似于styled-components，但提供了更多的灵活性和性能优化。
    
    
    
    • 官网: emotion.sh/
    
    
    • GitHub: github.com/emotion-js/…
    
    
    
    
  
  
  • GitHub Stars: 约17.7k（截至2025年4月）
  
  
  
  


• 原子化css
  
  
  
  
  • Tailwind CSS: 一种实用优先的CSS框架，让你可以通过低级实用程序类构建定制设计。
    
    
    
    
    • 官网: tailwindcss.com/
    
    
    • GitHub: github.com/tailwindlab…
    
    
    • GitHub Stars: 约87.2k（截至2025年4月）
    
    
    
    
  
  
  • UnoCSS: 新一代的原子化CSS引擎，旨在提供极致的性能和灵活性。
    
    
    
    
    • 官网: uno.antfu.me/
    
    
    • GitHub: github.com/unocss/unoc…
    
    
    • GitHub Stars: 约17.5k（截至2025年4月）
    
    
    
    
  
  
  • Windi CSS: 一个基于Tailwind CSS的即时按需CSS框架，提供了更快的开发体验。
    
    
    
    
    • 官网: windicss.org/
    
    
    • GitHub: github.com/windicss/wi…
    
    
    
    
  
  
  • GitHub Stars: 约6.5k（截至2025年4月）
  
  
  
  

3. 构建工具五花八门

构建工具是现代前端开发不可或缺的一部分，它们负责将源代码转换为生产环境可用的形式，并优化性能。

• Webpack: 一个模块打包工具，广泛用于复杂的前端项目中。它支持多种文件类型的处理，并具有强大的插件生态。
  
  
  
  
  • 官网: webpack.js.org/
  
  
  • GitHub: github.com/webpack/web…
  
  
  • GitHub Stars: 约65.2k（截至2025年4月）
  
  
  
  


• Vite: 由Vue.js作者尤雨溪开发的下一代前端构建工具，以其极快的冷启动速度和热更新闻名。
  
  
  
  
  • 官网: vitejs.dev/
  
  
  • GitHub: github.com/vitejs/vite
  
  
  • GitHub Stars: 约72.1k（截至2025年4月）
  
  
  
  


• Rollup: 一个专注于JavaScript库的打包工具，特别适合构建小型库或框架。
  
  
  
  
  • 官网: rollupjs.org/
  
  
  • GitHub: github.com/rollup/roll…
  
  
  • GitHub Stars: 约25.7k（截至2025年4月）
  
  
  
  


• Rspack: 一个基于Rust实现的高性能构建工具，兼容Webpack配置，旨在提供更快的构建速度。
  
  
  
  
  • 官网: rspack.dev/
  
  
  • GitHub: github.com/web-infra-d…
  
  
  • GitHub Stars: 约11.3k（截至2025年4月）
  
  
  
  


• esbuild: 一个用Go语言编写的极速打包工具，专为现代JavaScript项目设计。
  
  
  
  
  • 官网: esbuild.github.io/
  
  
  • GitHub: github.com/evanw/esbui…
  
  
  • GitHub Stars: 约38.8k（截至2025年4月）
  
  
  
  


• Turbopack: 由Next.js团队推出的下一代构建工具，号称比Webpack快700倍。
  
  
  
  
  • 官网: turbo.build/docs
  
  
  • GitHub: github.com/vercel/turb…
  
  
  • GitHub Stars: 约27.5k（截至2025年4月）
  
  
  
  


• Rolldown: 一个基于Rust的Rollup替代方案，旨在提供更快的构建速度和更高的性能。
  
  
  
  
  • 官网: rolldown.dev/
  
  
  • GitHub: github.com/rolldown/ro…
  
  
  • GitHub Stars: 约10.7k（截至2025年4月）
  
  
  
  

对比分析：

• Webpack 是目前最成熟的构建工具，生态系统庞大，但配置复杂度较高。


• Vite 凭借其快速的开发体验迅速崛起，尤其在中小型项目中表现优异。


• Rollup 更适合轻量级项目或库的构建，虽然社区规模较小，但在特定场景下非常高效。


• Rspack 和 esbuild 利用高性能语言（如Rust和Go）实现了极快的构建速度，适合对性能要求较高的项目。


• Turbopack 是新兴工具，主打极速构建，未来可能成为Webpack的有力竞争者。


• Rolldown 提供了另一种基于Rust的高速构建解决方案，特别针对Rollup用户群体。

4. 包管理工具逐步更新

• npm: Node.js默认的包管理器，允许开发者轻松地安装、共享和分发代码。
  
  
  
  
  • 官网: http://www.npmjs.com/
  
  
  • GitHub: github.com/npm/cli
  
  
  
  


• cnpm: npm在中国的镜像站，由于网络问题，很多中国开发者更倾向于使用cnpm。
  
  
  
  
  • GitHub: github.com/cnpm/cnpm
  
  
  
  


• Yarn: Facebook推出的一个快速、可靠、安全的依赖管理工具。
  
  
  
  
  • 官网: yarnpkg.com/
  
  
  • GitHub: github.com/yarnpkg/yar…
  
  
  
  


• pnpm: 快速且节省磁盘空间的包管理器。
  
  
  
  
  • 官网: pnpm.io/
  
  
  • GitHub: github.com/pnpm/pnpm
  
  
  
  

5. 状态管理百家争鸣

状态管理是前端开发中的重要组成部分，它帮助开发者有效地管理应用的状态变化。

• Redux: 经典的Flux实现，广泛用于React生态系统中，适合管理大型应用的状态。
  
  
  
  
  • 官网: redux.js.org/
  
  
  • GitHub: github.com/reduxjs/red…
  
  
  • GitHub Stars: 约61.1k（截至2025年4月）
  
  
  
  


• MobX: 响应式状态管理库，通过可观察对象实现自动化的状态更新。
  
  
  
  
  • 官网: mobx.js.org/
  
  
  • GitHub: github.com/mobxjs/mobx
  
  
  • GitHub Stars: 约27.8k（截至2025年4月）
  
  
  
  


• Zustand: 轻量级的状态管理解决方案，API简单且易于使用。
  
  
  
  
  • 官网: zustand-demo.pmnd.rs/
  
  
  • GitHub: github.com/pmndrs/zust…
  
  
  • GitHub Stars: 约51.7k（截至2025年4月）
  
  
  
  


• Jotai: 原子化状态管理库，专注于轻量级和灵活性。
  
  
  
  
  • 官网: jotai.org/
  
  
  • GitHub: github.com/pmndrs/jota…
  
  
  • GitHub Stars: 约19.8k（截至2025年4月）
  
  
  
  


• Recoil: Facebook推出的实验性状态管理库，专为React设计。
  
  
  
  
  • 官网: recoiljs.org/
  
  
  • GitHub: github.com/facebookexp…
  
  
  • GitHub Stars: 约19.6k（截至2025年4月）
  
  
  
  


• Pinia: Vue的下一代状态管理库，设计简洁且与Vue 3完美集成。
  
  
  
  
  • 官网: pinia.vuejs.org/
  
  
  • GitHub: github.com/vuejs/pinia
  
  
  • GitHub Stars: 约13.8k（截至2025年4月）
  
  
  
  

6. JavaScript运行时环境都有好几种

JavaScript运行时环境是现代前端和后端开发的核心部分，它决定了代码如何被解析和执行。以下是几种主流的JavaScript运行时环境：

• Node.js:
  
  
  
  
  • Node.js 是一个基于Chrome V8引擎的JavaScript运行时，广泛用于构建服务器端应用、命令行工具以及全栈开发。
  
  
  • 它拥有庞大的生态系统，npm作为其默认包管理器，已经成为全球最大的软件注册表。
  
  
  • 官网: nodejs.org/
  
  
  • GitHub: github.com/nodejs/node
  
  
  • GitHub Stars: 约111k（截至2025年4月）
  
  
  
  


• Deno:
  
  
  
  
  • Deno 是由Node.js的原作者Ryan Dahl创建的一个现代化JavaScript/TypeScript运行时，旨在解决Node.js的一些设计缺陷。
  
  
  • 它内置了对TypeScript的支持，并提供了更安全的权限模型（如文件系统访问需要显式授权）。
  
  
  • Deno还集成了标准库，无需依赖第三方模块即可完成许多常见任务。
  
  
  • 官网: deno.land/
  
  
  • GitHub: github.com/denoland/de…
  
  
  • GitHub Stars: 约103k（截至2025年4月）
  
  
  
  


• Bun:
  
  
  
  
  • Bun 是一个新兴的JavaScript运行时，旨在提供更快的性能和更高效的开发体验。
  
  
  • 它不仅可以用作运行时环境，还可以替代npm、Yarn等包管理工具，同时支持ES Modules和CommonJS。
  
  
  • Bun的目标是成为Node.js和Deno的强大竞争者，特别适合高性能需求的场景。
  
  
  • 官网: bun.sh/
  
  
  • GitHub: github.com/oven-sh/bun
  
  
  • GitHub Stars: 约77.5k（截至2025年4月）
  
  
  
  

对比分析：

• Node.js 是目前最成熟且广泛应用的JavaScript运行时，尤其在企业级项目中占据主导地位。


• Deno 提供了更现代化的设计理念，特别是在安全性、TypeScript支持和内置工具方面表现突出。


• Bun 是一个新兴的选手，凭借其极速的性能和多功能性迅速吸引了开发者关注，未来潜力巨大。

7. 跨平台开发

随着移动设备和多终端生态的普及，跨平台开发成为现代应用开发的重要方向。以下是几种主流的跨平台开发工具和技术：

• React Native:
  
  
  
  
  • React Native 是由Facebook推出的一个基于React的跨平台移动应用开发框架，允许开发者使用JavaScript和React构建原生性能的iOS和Android应用。
  
  
  • 它提供了丰富的社区支持和插件生态，适合需要快速迭代的项目。
  
  
  • 官网: reactnative.dev/
  
  
  • GitHub: github.com/facebook/re…
  
  
  • GitHub Stars: 约122k（截至2025年4月）
  
  
  
  


• Flutter:
  
  
  
  
  • Flutter 是由Google开发的一个开源UI框架，使用Dart语言构建高性能的跨平台应用。
  
  
  • 它通过自绘引擎渲染UI，提供了一致的用户体验，并支持Web、iOS、Android以及桌面端开发。
  
  
  • 官网: flutter.dev/
  
  
  • GitHub: github.com/flutter/flu…
  
  
  • GitHub Stars: 约170k（截至2025年4月）
  
  
  
  


• Electron:
  
  
  
  
  • Electron 是一个用于构建跨平台桌面应用的框架，基于Node.js和Chromium，广泛应用于桌面端应用开发。
  
  
  • 它允许开发者使用Web技术（HTML、CSS、JavaScript）构建功能强大的桌面应用，但可能会导致较大的应用体积。
  
  
  • 官网: http://www.electronjs.org/
  
  
  • GitHub: github.com/electron/el…
  
  
  • GitHub Stars: 约116k（截至2025年4月）
  
  
  
  


• Tauri:
  
  
  
  
  • Tauri 是一个轻量级的跨平台桌面应用框架，旨在替代Electron，提供更小的应用体积和更高的安全性。
  
  
  • 它利用系统的原生Webview来渲染UI，同时支持Rust作为后端语言，从而实现更高的性能。
  
  
  • 官网: tauri.app/
  
  
  • GitHub: github.com/tauri-apps/…
  
  
  • GitHub Stars: 约91.5k（截至2025年4月）
  
  
  
  


• Capacitor:
  
  
  
  
  • Capacitor 是由Ionic团队推出的一个跨平台工具，允许开发者将Web应用封装为原生应用。
  
  
  • 它支持iOS、Android和Web，并提供了丰富的插件生态，方便调用原生设备功能。
  
  
  • 官网: capacitorjs.com/
  
  
  • GitHub: github.com/ionic-team/…
  
  
  • GitHub Stars: 约13.1k（截至2025年4月）
  
  
  
  


• UniApp:
  
  
  
  
  • UniApp 是一个基于 Vue.js 的跨平台开发框架，能够将代码编译到多个平台，包括微信小程序、H5、iOS、Android以及其他小程序（如支付宝小程序、百度小程序等）。
  
  
  • 它的优势在于一次编写，多端运行，特别适合需要覆盖多个小程序平台的项目。
  
  
  • 官网: uniapp.dcloud.io/
  
  
  • GitHub: github.com/dcloudio/un…
  
  
  • GitHub Stars: 约40.6k（截至2025年4月）