神探狄仁杰现在是抖音一直给我推切片，确实有意思

B 站现在只刷关注，推荐的已经没救了，算法和抖音是肉眼可见的差距

两个解决方法：1 是静态文件传到静态资源服务器上，每次更新打包不删除上次的文件； 2 是每次打包生成一个版本号，然后页面轮训去查询是否版本更新，提醒用户刷新页面，这个有现成的插件，也可以自己手撸一个，不难

等赔偿就完事了，直接跟领导说等公司的辞退书

都服务端渲染了，直接前台开个页面下单不就行了？为什么要跳到 vue admin 去下单呢？

别人吹智驾也是吹自己家的智驾啊，难不成别人宣传都宣传的是你米的智驾可以在驾驶位上睡觉？离大谱了，怪余承东过度宣传也是怪他过度宣传自家啊，这是默认你米的智驾和其他智驾是一个水平的？米粉这搅浑水的能力有点儿幽默了

可以试驾一下智界 R7

@liudewa 还是信息不足，老系统没有页面，你们用什么形式接入？

看看老系统是怎么接入的，是 iframe 还是微前端，iframe 有 postMessage ，微前端都有通信的，你应该描述仔细一点

microApp ，京东的，虽然碰到一些问题，但是感觉比 qiankun 好用，侵入性比较低

先分析现状，再看达成目标。
LCP 我个人不是最主要的影响因素，最重要的是白屏时间和页面可操作时间，这两个时间短的话，页面的可访问性就有保障，我自己公司的项目做过一些这方面的优化，个人浅见分享一下。
最直观的就是做 SSR 或者 SSG ，vue2 也有 pre-render 相关的处理，可行的话也可以切换到 nuxtjs2 ，基本没有什么门槛。
资源加载方面该先检查服务器配置，gzip 或者 br ，http2 这些配置必须要有， 静态资源 cdn 加速也必不可少，资源根据需求做 cdn 缓存和预热，这个非常非常重要，服务器就是力大砖飞的东西，配置越好，网络越好，体验越好，在这个的基础上，你再去做优化，不然就是屎上雕花，毕竟巧妇难为无米之炊；
工程打包方面来讲，html 也可以预先做 dns 解析和资源缓存方面的优化，打包文件拆分这个很重要，一个资源 300k 我个人觉得有点太大了，我们所有的项目最大的公共包不会超过 150k ，不过在服务器和网络条件好的情况下，这个勉强能够接受，不要把不必要的插件和代码打包到公共文件里面去！举个例子 echart 和 lodash 这种一定是页面用到的地方才加载。不能拆出去的，能走 cdn 的尽量走 cdn ，尽量降低公共包里面无用的代码，ui 库和路由一定要做好按需加载，css 包可以用 purecss 这类的插件把没用到的资源去掉，当然这个得根据项目来调整。所有的 js 和 css 包括 html 都必须压缩！
从页面的方面来讲，所有的图片统一转换成最小的格式，可以通过 cdn 自带的格式转换，也可以通过工程化配置压缩文件体积，页面图片加载尽量做好懒加载。如果是 SSR ，一定要注意 async 和 await 的使用，多个非依赖的请求尽量并行请求。不追求 SEO 的话，能异步加载的模块都走客户端渲染，做好骨架屏能很大程度上提升体验，包括资源加载渲染的时候，可以参考有些项目运行热编译的时候页面有进度条提示。首屏没用到的元素也可以考虑做懒加载，举个我最近优化的 webview 嵌入的 H5 的例子， 我们业务有一个长列表的 collapse ，如果全量渲染，在正常的手机和 pc 上的速度是很正常的，在我们产品嵌入的低性能的安卓设备上页面 loading 时间会超过 10s ，这基本是不可接受的，优化加了列表和 collapse 内容的延迟加载，页面初始只渲染列表，页面 load 完之后会逐步加载 collapse 里面的内容，不影响页面的滚动和操作，优化后基本能保证在低性能设备上的访问速度和高性能设备差距不大。具体需求具体分析，各类框架的推荐写法一定要去看，保持良好的代码编写习惯，尽量不要往项目中堆屎和脑残逻辑
这些是针对首次访问用户的，其他的还有类似 pwa 和本地缓存的东西，可以针对多次访问的用户做优化，不过我感觉做好了资源缓存，这些配置可以根据需求选择性的去做，现在性能优化的文章和分享很多，都可以根据自己的项目需求去参考

我是 iqoo neo 9pro ，升级之后体验良好，感知最强的是信号好了特别多，之前地铁通勤没信号的地方都有信号了。bug 很少，丝滑流畅，耗电个人感觉稍微要快一点，不过可能和我电池损耗有关系，我觉得可以考虑升级

换成 vscode 了，copilot 也能用了

还在循环白嫖中

我觉得有 3 个点，大概率是前后端各打 50 大板。第一点：正常来讲，前端任何输入框都要限制长度，不然鬼知道会进来什么东西，前端肯定先背一口锅；第二点：你们接口没文档？接口有没有写清楚最大长度？需求有没有明确这些最基本的东西？目测你们大概率没有，没有产品和后端背全锅。第三点：接口有没有按规范约束返回？返回英文提示和 sql 报错甚至是 java 报错都是很傻逼的东西，前后台分离本身就是要遵循约定，返回英文报错本质上是后端想偷懒或者本身项目架构就有问题，除非是有约定码。前端如果直接在 ui 提示也是有问题的，一般 400 的错误信息都是要归类展示的，大概率是不可以后端给什么就显示什么的，前后端自查背锅完事。具体事情具体分析，开口就骂实不可取