咸鱼，最大的树莓派集散社区？/手动哭泣

来来来，捋一下（我理解的，非常直白的）定义：target = f(source)
可逆：从 target 可以反推出 source。例如压缩软件、加密算法等。hash 算法不是可逆的，理论上一个 hash 对应无数个 source。
编码：用一种规则 f 把表达 A 替换成表达 B。例如翻译软件、GBK2UTF8、Base64 等。一般来说编码总是可逆的，唯一需要的知识只是规则 f 本身而已。
加密：target = f(source,secret)，加入了 secret 并确保在不知道 secret 的前提下无法（或者代价超大）从 target 反推 source。
对称 /非对称：加解密用的 secret 是相同的，叫对称。不同，叫非对称。
编码 vs 加密：古代经典密码学语境下，由于编码规则的复杂和不可知（就像一个小学生根本不知道 base64 这一开放普及标准），经常把编码也称作加密。但在现代计算机语境下，大家都区分开这两种说法了。

以上都是直白表达。更抽象更准确的可以翻 wiki，都有定义。
讨论问题先厘清概念。概念认识有分歧的基础上还大放厥词骂人沙雕的，真是过于自信了。

如果不稳定 /挂掉的站点可以得 1 分，稳定的站点起码超过它 100%，得 2 分。
所以 lz 说的没错，完全正确，稳定性确实是网站的评估标准之一，我支持你！

当然有优质内容的并且经常更新的原创网站得了 100000000000000 分这种事情我是不会随便乱说的。

这年头短信只有一种用途：验证码。需要验证码的时候一般手机就在手里。
所以关短信提示音+熊猫吃短信，隔天半月的打开短信瞄一眼都没误过什么事，因为根本没事可误。

骚扰电话来说，腾讯手机管家的识别率还不错。见到骚扰电话秒接，然后该干嘛干嘛去。

同意 @flowfire
业内混个几年，基本上心里会有一个谱，遇到一个问题的时候各个环节出幺蛾子的概率排行榜。

比起骨干网、运营商、本地网络、操作失误等链条上的所有其他环节，8888 简直可以说坚如磐石了。

前提：新手。新手的特点就是对任何问题都不熟，很有可能被一个很初级的问题莫名其妙卡住。

而设计简洁和使用简单完全是两码事。。。
使用简单适合新手。设计简洁。。。新手怎么评估和享受设计？

换行符
tab/空格
文件权限
代码提交三大新手坑。

至于全角空格希伯来字母之类的神迹就比较少见了，反而处理比较简单，二进制比较确诊，git blame 溯源，拉出去打死就完事了。

@also24 嘛，我的意思是想和你探讨“不开发网页版” 和 “明明有网页版但功能不全”核心原因其实是一致的。也可能我误读了你的意思。
如有打扰请谅解。

@also24
除了某些根本不可能网页版的玩意（例熊猫吃短信），其余不开发 xx 版和根本没有 xx 版的众多产品核心价值观其实是相同的（此处 xx 不限于网页，还有 iOS、Android、小程序、公众号、阿里公众号、WinPhone、YunOS 等）：
1，投入产出比。最根本的因素。完全放弃，或者做个简单版纯做引流作用。
2，自我封闭和保护。网页架构开放，容易被攻击、被爬取，防御成本高。app 相对私有封闭，防御成本低效果好。
3，触达成本。这个因素是反向的：小程序低，公众号低，网页中低，app 高。这个因素和因素 1 也挂钩。

至于什么天朝特色就不用扯了，天朝只有政治特色，没有什么经济、市场特色。而互联网领域整体来说算是天朝内天朝特色最淡领域之一了。

@murmur 唉。。。不加狗头就经常死的很惨。。。求个厚葬不知道还来不来得及？

翻了翻我的手机：
即刻、百词斩、开发者头条、我的天气、Newsify、Keep、喜马拉雅、我的世界、梦幻家园、B612、OVLA、Prisma、WhatsApp、Telegram、Any.Do 、暴雪安全令、Google Authenticator、形色、榫卯、Knots3D、熊猫吃短信。。。麻蛋罄竹难书！
以上产品统统歧视网页用户，它们甚至根本没！有！网！页！版！
呸呸呸天朝特色天朝特色。。。
（什么里面混入了非天朝的 app ？那它们也肯定是天朝特色病的携带者）

方案各位大佬提了很多了。我只提醒一个事情：
自己暂时不会 -> 学习成本高->时间久 千万不要推导出 ->复杂方案不用。
自己熟悉的技术 -> 无学习成本 -> 千万不要推导出 -> 这就是简单方案。

这两件事，不等同。
哪怕是再简单的系统，用 PHP 实现文件缓存、共享内存等思路为啥大家都不用？
那是因为千万人都认为 redis/memcache 才是真·简单啊。

分活，明确成为文档 /邮件 /任务管理工具等，然后做自己的部分。进度公开，确保上级可以看到。
等做到相互依赖部分，如果有阻塞，沟通为先，实在不行提前上报风险，随时更新进度。

吐个槽，这个梗难道不应该是“马上要 9102 ”吗？/doge

支付宝在“日出斗金”文件夹。
饿了么在“衣带渐窄”文件夹。
定位精准，不会混淆。

提点建议：
0，三种人不是用户群：a，阅读英文速度不比中文慢的。b，宁可忍着慢速也要提升自我的。c，编程领域神圣不许其他语言僭越的。咱们就忽略即可不抨击了吧。。。
1，lz 的初衷是能快速扫描代码观其大略，精要是鸟瞰，是忽略细节而不是扭曲细节。不如按层级翻译（比如类名 > 方法名 > 变量名）。细节实现就放着好了。层级设置可控就更好了。
2，无论是翻译到什么级别，对于命名的翻译，一定别忘了借鉴下划线、驼峰等天然分词符。人家都帮你分好了不用白不用。
2，仅针对快速阅读理解来说，注释的重要性远大于源码实现细节。
3，一定要做语法解析，至少做到词法解析吧。源码这种东西，千万不能按文本处理。
4，一定要做全文翻译或者句级别的翻译，眼看着 9102 年了千万不能以单词为单位会死人的。

1，理论上你应该把“出了任何问题，通过日志可以分析出原因”作为目标去追求。毕竟后端有很多很微妙的 bug 或者漏洞很难重现。日志应该是最有力的分析工具。如果分析不出来，说明你没记录好。
2，try/catch 我是这样使用的：
2.1，可预期的，自己可处理的一般会拆成小的 try 当场给结论或者当场恢复掉。
2.2，原则上不会给调用方暴露原始异常信息，一定是经过掩饰或者二次处理的信息。这个操作可以在业务层，也可以在中间件或者框架层。
2.3，至于具体谁负责，看情况。有时候多方共同处理 /记录然后 rethrow 出去给上层做不同层面的处理也是常见的。