@Solix 2 已经很不错了，另外团队应该配合越来越默契了。
@runtime0 ai 本该成为提供工作效率的工具，这样变成一些人偷懒的工具了，个人觉得长期以往，团队的问题早晚会爆发。除非 ai 能成为一个比较完美的超级个体工具，上下游岗位，啥都能用 ai 做的不错。
@runtime0 话说你们一个常规的需求（定义：一个产品花多少天做出来的需求）的完整开发周期是多久
@xyzlucky 很强，很羡慕团队里面有这样的产品。真心话，如果需求周期要求温和，产品都能像你这样，应该能够降低大量下游岗位的沟通成本。
@LoongCLL 所以产品在这个过程扮演了什么角色😅，看起快速迭代，实际上开发周期估计也少不了多少，后期埋坑估计也不少。据我观察，一般团队里，都会有一个只管向上汇报的传话筒，上面说什么就迎合，不消化需求，形成产品，最终问题都流传到下游岗位。
@shawn4me 加油，多沟通吧，实在无法继续沟通，只能多提升自己，早日换个正常点的团队了。

@adimn 啊？深表同情，听你这么说，对面感觉不像一个产品。说到开会，不得不吐槽另外一点，在我们产品的认知里：开一个 1-3 小时的会，会上所有谈过的内容表示你都掌握了，ta 花一周做的需求，会后敢问某些原型上没量化的细节，跟仇人一样。😂

@cairnechen 谢谢回复，理解，快速迭代时是这样的，文字表达问题不大，主要是逻辑清晰，结构化表达，语言精炼，纲要叙事线路明朗。是的，磨合和沟通是必要的。

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

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

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

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

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

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

之前我提过类似的问题，可以参考下：
https://www.v2ex.com/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.https://i.imgur.com/uuDfmlM.png

2.https://i.imgur.com/7m2Ufis.png

3.https://i.imgur.com/W4b2ivF.png


可能我没描述好，我说的是，我在另外一个类 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 这种方式)？😅

@markzyh 嗯嗯。b.vue 我采用 md 的 html 写法，代码是手敲的，v 站对部分代码的解析效果似乎不大好，不管我怎么缩进就是输入框的代码格式就是≠预览的格式，下次我用 ide 格式化看看。抱歉，import 手敲错位置，v 站改不了帖子。谢谢建议。

谢谢大家抽空回复！
@moreant 请教一下 v3 这波改动，是放弃在组件里使用 export 了吗？加了<script setup> 提示的错误，发现答案大部分是删除掉 export 的部分，回归普通 js 的写法？ https://stackoverflow.com/questions/71163741/vuejs-script-setup-cannot-contain-es-module-exports

@cxe2v @grit136907108 好的，确实写错位置了。
@foolnius 我问题里就是类似这么用的😂。

@SleepyRaven 啥剪辑软件？“Thomas 看看世界”确实厉害，不过个人感觉他的风光摄影比较专业，偏技术型的，作品也主要以相片为主，对于普通人来说，风光视频可能包含更多的视觉冲击力和内涵。
@coolmint 我还以为登记后就没问了呢，6 。

@aikilan 嗯，西藏和新疆 基本上是国内自然风景最漂亮的地方，有山有水，地缘辽阔，而且同个景点不同季节的景色和看点差异很大，只可惜海拔太高了，一大部分人可能需要阶段性过度才能适应高原生活，而且这两地区景点跨度太大了，一般需要花比较长时间在路上，而一般旅客的旅游时间又不会太长，所以很难成为短途旅行的选择，自驾一般是相对比较好的选择，不过高原山地地区，路面狭窄，山路崎岖，得老司机带路才行，并且最好有同伴相随，中途开累了可以轮着开。所以个人建议想去的 v 友，选好合适的季节，选一些景点相对集中的地方去，不过相应的游客可能会比较多。
@ahu 是的

@coolmint 哈哈，先练习练习，不过一般得登记
@imaning 不是我搞的视频，是我昨天偶尔看到的视频，只是觉得他把西藏风光跟西藏有关的科学研究 /历史相结合，挺不错的，以前还是从事 IT 行业，之前看到区里有些人总在为大龄再就业问题焦虑，虽然不大现实，但还是想分享一下博主的一种选择给大家。哈哈，其实我觉得他要是把中文字幕去掉换成自动翻译或者出个双语版的字幕估计有更多人看。

@ll0504 感觉我抢了你的名字。😂

哈哈，忘记说了，本人非前端开发者。
@Aloento @westoy
主要是排版问题只需要换个方向就行了吗？会不会有兼容性问题或者美观上受影响之类的？