OldCarMan

个人觉得可以这样，4 步走：

1.解决业务可扩展性问题：可以让前端使用图片编辑器生成图片信息，如果业务需求是后续不可编辑可以生成截图保存，如果是可编辑的可以把整个编辑后的图片 html 保存，建议把其上传到对象存储；

2.前端将图片编辑结果提交给后端服务，后端将 html 信息+业务参数封装，丢到消息队列里面。

3.html->图片，这一步可以考虑各种各样的处理方式，根据自己的要求(比如性能要求)去搜索相关的库，比如 html to image java/nodejs/c++/rust 等等，生产完将结果上传并丢回消息队列里面，这个胶水层服务提供：消息队列消费，生产；图片处理；图片上传的服务。

4.后端服务消费胶水层服务产生的图片 url

目的：1.解决扩展性； 2.吞吐量； 3.图片业务与主业务的解耦，数据量大时，图片业务硬件资源吃的较多，可以单独升级图片处理服务。

之前我提过类似的问题，可以参考下：
t/920810

不过个人觉得，可能对于大部分人，只是看看相关的库在开源社区的数据表现，以此作为使用的判断条件，有时间和能力当然在使用前 review 一下最好，反之，如果有这个担心，可以先在隔离环境先跑一下，观察存不存在使用异常，或者做好环境监测，尽量做到快速反馈和现场保护。

@letsky 谢谢回复
@luckykev1n 谢谢回复，你 2 楼回复的：
ParameterizedType paraType = (ParameterizedType) listenerType;
类型无法转换（ java.lang.ClassCastException: class java.lang.Class cannot be cast to class java.lang.reflect.ParameterizedType ）。

1.

2.

3.


可能我没描述好，我说的是，我在另外一个类 Cache.java 里面接收 UserListener 时，无法获取到泛型接口 UserListener<T extends User>相应的泛型 T 类型:
public class Cache{
-----

public static void addUserListener(UserListener<T extends User> userListener){

在这里无法直接获取得到 userListener 的相应的泛型 T 类型

}

-----

}

谢谢回复。不过这样会不会不大规范，毕竟代码扩散到各种地方，维护管理起来比较麻烦。

@clue 学习了，谢谢告知。

@ilovey482i @perfectlife @bootvue jira 体验怎么样？如果禅道和 confluence 的功能都有的话，是不是意味着开发 /测试 /产品都能用？
@idolud @xuelu520 tapd 怎么样？一般谁（开发 /测试 /产品）在用？
@Worldispow @sadfQED2 哈哈，说到钉钉，好奇为啥没人说飞书的？不过这些都不支持内网部署。
@brader +1 ，不知道现在的 confluence 和禅道产品迭代的怎么样了，之前使用时还在 conference 上写过 api 文档，但也只能一个个写，效率低下，产品也会用它来写需求文档，至于禅道，感觉要是能接入自动化接口 /功能测试以及 bug 修复后的自动测试就好了。
谢谢大家回复！

谢谢大家回复

@foolnius 嗯嗯，个人觉得这样做是不是有点冗余了，如果每个组件内部都这样调用，岂不是一堆重复逻辑的代码。v3 是不是发现 v2 这样写的问题了，所以才使用 <script setup>的方式来规避这个问题？ （非前端评价可能不专业）

接#6 楼我写的。
换成 v3<script setup>后，我发现组件里<script>下几乎所有的代码都换了个使用语法，无论是基本使用语法还是组件间的通信写法，基本等于回归原生 js 的使用习惯，虽然代码逻辑上基本不变，但是这改动未免太大了吧？如果老项目使用 v3 以下版本，是不是基本放弃体验 v3 相应的版本升级内容了，虽然可以选择不用<script setup>这种形式，只能绕道而行？继续保留使用<script>或者写多个<script>(其中一些使用 setup 这种方式)？