@win7pro 说的对, 从 0 开始做的产品, 怎么会不加班呢? 只有成熟的产品, 每个月只做迭代开发的时候加班才会少一点, 楼主一时辞职一时爽, 一直辞职一直爽, 先用门框把自己的脑子夹一下, 再把前同事打一顿, 最后炒了老板

还是比较喜欢 sublime, 不喜欢 vscode 的风格

有时是方便调试, 有时候是因为这段代码所实现的业务当前不需要了, 但是不保证后续不再继续启用, 很正常...........重要的是,直接注释掉更直观.....当然, 如果太多了也会影响代码阅读

自从在搜狐追了 法医秦明 2 我就有一个感觉, 搜狐是真的越来越不行了.. 优酷今年出了不少过得去电视剧(长安是真不错), 爱奇艺就是各种综艺节目, 搜狐呢????搜狐很符合张朝阳的气质, 好好锻炼身体, 熬垮它们.........................

估计也就是第二个百度而已

@linbingcheng 是上传图片, 目前还没有允许用户上传文本文件的功能 , 至于你说的安全问题, 不知道你担心的是否为恶意用户上传可执行的恶意脚本的问题? 我这里有根据图片内容去判断上传文件是否为图片(不是判断图片尾缀), 如果不是图片文件就不进行保存. 目前也只是做到这一层面的安全验证了.

@wuwukai007 我每天都摸-------咸鱼, 最近脚气好像又犯了, 香菇蓝瘦.............

哈哈哈, 这个头像好像一坨屎

@crella 后台在数据表就保存图片的目录限制住了(需要实现某些需求导致的问题), 后续看情况会搭建专门的服务器保存图片

@yidinghe 刚测试了一下, 在本机测试, 本机浏览器随机访问 nginx 进而获取某个目录的某张图片, 固态硬盘, 复制了 10 万张图片(这里应该远远不止 3w 的说法, 但与文件系统, inode 有关系, inode 用完, 就算磁盘空间再大也写不进去的), 察觉不到任何延迟, 只是进行 ls 之类的操作时有点卡顿现象(应该会随着文件数越大越明显).......如果是这样的话, 项目估计上线以后还能撑一段时间..............看来我就是一个得过且过的程序员..................

@alcarl 预估达不到百万级的数据量, 正在写个脚本测一下, 至于容灾方面的东西, 估计得后续看项目运营情况, 小公司, 小项目,成本有限

@arrow8899 我在很多地方查询到的答案和你的理解都比较类似

@abcbuzhiming 后续看项目发展吧, 起不来, 肯定不去考虑这些了

@abcbuzhiming 文件系统的差异影响的是最大数量, 这点是知道的, 疑惑的就是在不超过最大数量的前提下, 当数量达到多少, 通过 nginx 读取图片时, 会出现体验过差, 应该还是磁盘 io 性能的限制

@xjtufreeman 后续会考虑

@bkmi 多台 web server 其实也可以做到直接保存到本地目录的, 比如在 nginx 配置一下, 当然还是看需求

@eonboy 文件系统的格式限制的是单个目录下的文件数量, 整个服务器的文件数量应该与系统的 inod 有关

还是觉得, 如果不是什么 leader 之类的话, 最好不要随随便便给新人什么意见和建议之类的东西,,,,,,,,,

@YIsion 假设带宽, 服务器硬件资源都能满足, 单个目录下保存了大量的图片, 通过 nginx 访问获取. 在这样的前提条件下, 想知道这个数量瓶颈在哪里, 不是 ls 之类的操作.........