随便写点儿吧就。
每次新开项目搞基建时都好头疼，webpack 太难用了，配置搞上几天才能把项目跑起来。也反思过，为啥每次都有问题，可能是因为隔很久才会新建项目，这么久过去，依赖的包升级了，使用方法可能也变了，也不能一直用旧版啊，或者出了新技术，唉，老了，技术更新太快了，跟不上了。比如今年的年度报告打算用 tsx 写，去年没有用，所以今年重新搭了架子，花了好久才搭起来。
还有，去年的年度报告是 swiper 6.3，几年是最新版 7.3.0，可以直接用
年度报告真的是今年做得最累的项目了，不过去年的有些代码也能复用，跟去年相比还算省了点力气。但奇怪的是为什么还是这么累。
复盘一下： 最后的海报分享页跟去年不同，完全重写，去年花在开屏页面的 canvas 上很久时间，今年的时间有不少是花在最后的分享页面的，而且是花在支持旧版 iOS 上。像 skew() 加渐变，在老safari 里支持不太好，花了不少时间来解决。
一个今年年度书影音报告海报分享页的血泪经验总结：
前提
- 海报预览页面需要书影音三种类型切换预览，并带有淡入淡出渐变效果。
- 因为预览页面和分享页面高度相似，所以其实是使用同一个 screenshot_preview 组件，在组件里根据是不是分享页来决定是否显示切换按钮等预览页独有元素。
最早的方案1： 如果用户在左边按钮选择了图书，右边就只渲染展示图书内容。 但发现这样每次切换类型时， dom重新渲染会导致条目封面图都重新请求，有点浪费cdn带宽
第2次的方案： 在 dom 里一次性把书影音三种类型全部 map() 渲染出来，使用 absolute + index + opacity 来处理淡入淡出。切换类型时，只展示最上层的类型，可以避免切换类型时重新请求条目封面。
上线后，部分旧机型（iPhone 8 / iOS 11）反馈在调起分享卡片时，卡片窗口空白。经过一夜艰苦的 debug，发现是页面布局全部用了 absolute 的关系？
一个猜测： 在旧的机型里，分享卡片的窗口是没有高度的，需要页面里的内容撑起外面的窗口。
但因为页面内容都是相对于外层窗口进行绝对定位，所以外层窗口没有高度时，里面内容也就没有高度，导致页面无法展示
第3次的方案： 重构页面布局。只在预览的时候，才使用 absolute ；分享的时候，不用 absolute， 而是通过页面内元素高度撑起外部的窗口。一个组件支持两种布局。
第4次的方案： 第3次的方案上线后，发现有部分用户的海报分享图头尾缺失。继续 debug，换了俩方案：计算背景图高宽，和直接用 img 宽度 100% 撑起高度，这期间还遭遇了 webpack 用上 url-loader 后，可以在 tsx 的 img 里正常 import 图片，但却会导致 scss 里的背景图出不来的问题，花了几个小时修，还是放弃了，img 的 src 改成了写死的 cdn 图片地址，这样就不会被替换了。但最后发现之前头尾缺失的原因，可能是因为老旧浏览器不支持 flex-direction: column 导致？但 webpack 里明明设置了 autoprefixer 啊，不知道为什么没起作用，查了一下，发现 webpack5 可以直接用 postcss-preset-env ？于是又用 postcss-preset-env 替换了 autoprefixer，终于正常了。
上面只是页面开发的一个小细节。总体来讲，论上线后遭遇的问题，今年的年度报告比去年轻松了，不过还是一波三折。
有了去年的经验，今年提前预留了几个出错时去爱豆小组反馈的入口，网络请求出错、后端数据解析出错、模板渲染出错、代码语法出错。结果页面上线后，刷来刷去里面就一条反馈。一度有点清闲，感慨没有去年上线那么刺激了。
正开心呢，无意间发现有人给我发豆邮反馈，在未关注人豆邮里，之前都没发现。说自己没在爱豆组，所以发豆邮反馈了。开始觉得事情不妙，去爱豆组一看，好么！爱豆小组什么时候改成申请才能进了！？火速让金同帮忙看有多少入组申请，大概 20 来人。赶紧！全部通过！我这边又火速新建了一个小组，专门用来反馈年度报告，不能再用爱豆组了。火速让运营通过小组创建申请！太过匆忙还把小组名写错了，改完组名后火速起了个 group 的 pre，自己去管理后台把修改审核通过。又火速把页面代码里的反馈入口改成新的小组，ok，上线！用户反馈慢慢进来了。
说到这儿，就引出一个问题。年度报告这种项目，用户遇到问题，一般直接就反馈到我这里，再由我这边判断是什么类型的问题，后端还是算法，然后分发出去。基本就是充当客服了。甚至不止是用户，上线之前，产品、设计 review 时也是，基本上不管什么问题，先找到我这儿。一边还在开发，一边还得兼顾 review 那边提的问题。 提的问题都放在 trello ，但感觉 trello 不好用了。照着 trello 去飞书找人问，就非常分裂。明年项目开始之前得想想这个流程怎么优化下。
今年 review 进行到差不多一半时，我们几个人开了一个会，讨论几个疑难问题怎么分工。会上我提出让测试在各种手机上测试一下。有王琪社区报告页面上线出问题在先，我觉得还是让测试先过一遍好心里有底。后续王俊杰他们也测试了，介入的时间还行，当时距离上线还有一周，提了俩问题，其中一个就是白屏的问题。当时我没在意，觉得是手机自己的问题；还有一个是 iPad 样式兼容问题，设计那边说不考虑 iPad ，所以就没处理了。当时我在忙着处理 trello 里产品和设计提的六七十个问题，想用一周时间全处理完，周六日的时候再处理测试那边的问题。
结果周六日都在完善动画效果和翻页效果，没顾得上测试提的那个白屏问题。
周一上线之后果然中招了。不过受影响的用户规模不大。
现在，线上用户反馈的前端问题都修完了，就剩下一个网络问题没找到原因。总有用户反馈打不开页面，页面进去后就提示网络错误，接口请求失败。我让用户直接访问接口地址，接口返回是的 404，奇怪。接口在 sns，但 onimaru 里 sns 也没看到相关报错，后端找不到原因，觉得是用户网络不稳定，说是千分之三的比例，看起来不太愿意修的样子。还得我去翻后端代码查问题可能出在什么地方，把代码发给后端帮忙看。结果发现后端早就下班走人，都不理我了。
零零碎碎，流水账，东一榔头西一棒子就先写到这儿吧，主要是年度报告的一点感想。