去哪煮米上看吧： https://www.nazhumi.com/

MUD 还存在，比如：北大侠客行

华西～天天一瓶 10.5 的

真一： https://zhen.one ，RSS： https://zhen.one/atom.xml 。
感谢关注， 一直在输出~

业务决定产品

楼主不嫌弃的话，可以瞅瞅我这个 demo ，内容很精简，同时还集成了 websocket：
https://github.com/w4ngzhen/nest-http-websocket-demo

说下思路吧。首先，这个“输入框”从上到下需要分为三个部分：
1. 实际的输入框；
2. 展示上传图片的地方；
3. 圈子选择。
然后，思考一下这里的数据模型。大概这样：
{
inputText: string;
// 这里是放置上传的媒体数据，是一个数组，每一项 thumbnailUrl 是这个媒体资源的缩略图； resUrl 是媒体资源的实际 URL ； localPath 是初始传上来，没有传到后端的文件路径； resType 就是资源类型（图片 or 视频）
mediaResInfo: Array<{ thumbnailUrl: string; resUrl: string; localPath:string; resType: string }>;
groupInfo: string; // 不知道具体什么，就用个 string 吧
}
顶部实际的输入框是一个完全无边框的 input ，每次 onChange 修改的是 inputText ；
下方的缩略图呈现区域你用图片 img 来渲染；整个组件接受图片拖入的事件，如果是图片，你可以直接将图片放到这里（由于大小原因，直接缩放了），不需要缩略图 url ；如果是视频，则你可能需要一个服务（我不太清楚这块还有什么方式获取视频首帧图片）来获取视频首帧图片，得到一个 URL ，进行展示。

最下方的圈子选择不多说的。

至于你说的二选一功能，只需要考虑，上面数据模型中的检查媒体资源中的 resType 是否满足二选一的要求，不满足就不能再传了，（也就是对拖入事件不处理）；

外面手机大概写的，思路就是围绕数据，上面界面只是呈现数据的结果。大概这个思路哈。

个人的理解，redux 不适合业务项目，适合一些底层框架使用。举个例子，比如做一个某些领域的低代码底层，使用 redux 可以很好的控制低开中的数据流。

啥时候来成都呀🤩

个人推荐矮人要塞，会了以后其乐无穷

更加推荐 rm 别名到 cp 等，把删除的内容放到临时目录下。至于 rm 加上确认 prompt ，可能短期有用，但是长期很容易养成一路 yes 的习惯，实际上没啥大用处。

想起以前看的留言终结者，一直变道试图找到最快路线的开车方式和基本不变道差不了几分钟。另外，其实估算也算的出来，高速上 120km/h ，跑 120km 花 60min ，如果跑到 140km/h ，也就 51min 。两者相差 9min ，也就服务区简单休息撒泡尿的时间，这还是你冒着高风险且一直不减速的结果。

大佬好，请问这个图床纯用爱发电么？

@bnrwnjyw “编制有什么好的” 大哥，人家媳妇是北京在编教师。。。

用微信账号？我以前一直用微信侧账号登陆的 QQ 音乐，但是现在又切回 QQ 账号了，最大的问题就是在京东、淘宝上充值 QQ 年费，很多的店铺只支持 QQ 账号充值。

大家不要纠结 master 分支包含未完成代码，分支只是一个名，“master”、“dev”当开发分支不过就是名字，各家有各家自己的设定，只不过开源项目约定俗成的是 master/main 分支作为稳定主干。楼主的场景下，应该秉持哪里出问题，哪里拉分支处理。你如果是线上问题，你就该从 prod 分支（假设你们是这个分支作为线上，或者你们至少发布的时候有一个 tag 吧）拉一个 hotfix ，因为这才是和你线上绝对一致的代码环境。hotfix 完成以后，应该将你这个 hotfix 分支在你们的开发/测试/预发（假设有）/生产，这么走一遍，进行验证。hotfix 的首要目的是快速修复。
上面的事情搞定后，你可以把 hotfix 里面的 commit ，再 cherry-pick 到你现在的开发环境等，部署一遍，这个过程就和普通开发流程一致。