官网英文，建议最好重新斟酌一下，感觉会影响客户印象，我见过设计师设计稿英文字母写错不得不撤回的情况：

we are young designers and focused on brand identity
=>
we are young designers and focusing on brand identity.

hello, if you interest working together. just send message contact page
=>
Hi, if you are interested in working together, just contact us.(如果按原文改的话应该是 just send us message on contact page)

个人意见，仅供参考。

@bigfei 这个本质上和 lz 的还是不一样的，lz 的需求是省空间，删除不必要文件。而 tree shaking 是将已经引入的 js 进行处理，减少无用代码。在引入时尽量最小化引入，比如上面举例的 lodash，不引入整个只引入需要的函数。

假若像你说的保留 tab 方便跳到其他，下个需求应该就是希望在这种情况下把朋友圈放在 tab 方便跳回来。底部没有 tab 另一个原因大概是在需要阅读的功能界面减少阅读干扰。

订阅号阅读，朋友圈，钱包都是属于一级 tab 下的功能，一方面是层级不同无法并入 tab，一方面是这其实是个十分明确的交互操作，用户知道在哪里找到哪个功能，用户知道返回就能回到上一级，就好像很早以前对普通用户来说 打开导航网站 -> 搜索百度 -> 进入百度 -> 搜索要找的网站名字(举例) 虽然长但是明确无歧义。这里应该是有优化空间的，只是可能没有达到这样的明确性。目前只有从一级到二级的快捷功能，比如扫一扫和付款，但无法做到从二级到一级，在二级界面添加快捷功能都不如一个大家都知道的返回好用，而且容易丑。

好了，我编不下去了。

Github 对 issue 有着莫名的偏执，可以删除评论修改评论却不能删除，只能 lock, block，很多管理功能缺失，导致开源作者在这上面花费大量时间。正在准备一个简单的社区来替换掉 issue。

@kslr 谢谢。主要成本不在于上面提到的那些，主要是投入的精力和接下来没法继续公益投入的精力，寻求一个方式让项目继续健康维护下去。在有所回报有所鼓励的情况下我甚至招兼职来维护也是可以的。考虑过挂常规广告，但是总觉得不优雅，所以如果有类 V2EX 右侧的广告商是比较 ok 的。


@Showfom 谢谢 showfom 大佬，我的几个域名还是大学时间在你那边注册的。


@huiyifyj 试过，也挂在项目中，国情原因，0 捐赠，后来撤了。patreon 也有 https://www.patreon.com/airyland


@wzw 十分感谢。

@gamelyking 额，手动写个解析转或者用网上的工具，具体哪个论坛？

转成 rss 用 rss 阅读器。

如果暂时不能确定到具体问题，可以在一个或者多个抓取任务结束后，直接 process.exit(1)，pm2 会自动重启，还也可以定义 restart delay。

楼主可以举几个例子，我拿来测试下我的一个抽取工具能不能用

很清新。看了下规则，一次拍卖下来总共是 5% 服务费 + 2% 提现费么？

宽度似乎不适合两栏，文章很长时看左栏拉到底，视觉看受右栏干扰，然后再拉到顶端看右栏是挺奇怪的。

@yuanfnadi 好问题，需要关注公众号(或者其他方式)获取一个用户 client_id，chrome 插件在提交时生成一个 token(逻辑代码混淆提高伪造难度)，后台也会有频率监控，超过某个设定频率的也必定是错误数据，另外后端也会校验提交的数据，因为前端不清楚逻辑不好伪造，多次尝试失败后端就可以拉黑这个 client 了。

@EarthChild 就事论事啊，如果从事实出发有人评价你所在的公司部门很好，别人非要说你所在公司另一部门很烂所以你们部门也烂，那这个就没法讨论了。

一个免费产品加了一个其实考虑到用户体验的广告，你们说作恶了。一个免费产品收费了，你们就发帖说哪里有免费替代品。一个免费产品倒闭了，大概也想不起自己没任何支持，反正我用是给你面子。要求其他人尊重开发者劳动的是这群人，反之也是这群人。如果换成一款个人开发者维护的软件呢？即使大公司也没有多年公益维护一款免费软件的义务。

@luoyou1014 这看起来是代码没有 review 团队没有规范导致的吧。

当然是二，该是数字的应该是数字，该是布尔的就该是布尔。第一种写法的可能还会要求你把原该是数字、布尔用字符传参 post。如果前端使用了 Vue, React 组件，那么意味着渲染前你要转换一次，提交前要重新转换一次，实在是浪费不必要的时间。

作者部分也改了，大概是流量焦虑吧，过去微信的动作都太慢了。

1.微信文章有相对干净的短地址 http://mp.weixin.qq.com/s/{大概 22 位的字母数字}
2.早期参数多是因为 url 以单个群发为主体，需要 mid 来确定群发，需要 idx 判别群发第 n 个文章，需要公众号 biz 来优化查找或者防采集(猜测)，sn 参数应该是消息校验 hash。chksm 不一定需要，在不同的参数场景时可能需要。

主要还是防采集，就像订单号我们不会用递增数字一样，微信文章数据的价值比没落的贴吧大，所以网上有 n 多的不断失效的采集教程，也有多个以微信数据为核心的付费服务商。即使现在有短地址，构成为 22 位字符，也做不到盲采。