这些话题不同时代重重复复、各种问法一直产生，甚至将来百年、千年都会存在，只是里面的词变了而已
“机器会让我们失业吗？” 这代人没遇到这个问题，但影视、小说里面总见过吧？
“电脑会让我们失业吗？” 我起码听过这句话，事实上电脑确实让我老妈提前退休了，当时叫“下岗”
“人工智能会让我们失业吗？” 新一代的问题
将来呢？

;TLNW 太长，不写了
直接上结论：会，淘汰部分落后技术；&不会，催生新行业、新分工，走向新发展

如果什么都不会，那就必须守一条：
自定止赢、止损点，到点就卖，不管后面是涨还是跌，当然这两个点之间不能太宽

但是
99%的人都无法遵守自己定下的止赢、止损点的，能做到的人其实是可以做大事了，不必炒股，因为意志力太强大了

@sutking #25
首先，放在最前面，我并没有否定你说的

我认为你说的原因是其中之一，但也有其他可能（我就是列了其他可能）
只要排除其他的，那你说的自然就是唯一可能

你可以去查 EXIF 标准，我们常说的 exif 其实是广义，里面还包含好几段信息：
Image 信息、EXIF 信息、GPS 信息、缩略图信息……共有上百条记录
不是所有相机、设备、软件都会全部记录这上百条，不然文件就有点大，它们会选择记录其中的某些，这就是我说的第一点 —— 有没有记录要看拍照软件，这个有没有是指“有没有哪些”，例如有时间但没有 GPS 是很常见的

既然上面说的可能有些记录有，有些记录没有，修改时自然也可能选择只删除少部分（或者说代码写差了，忘了拷贝 EXIF ），这就是我说的第二条
而且，修改 APP 未必就是额外的，也可“拍照+修改”是同一个 APP，拍照的模块记录了，P 图的模块写漏了，也有可能
我就有个程序是专门删除 copyright 这条记录的，其他 exif 记录不变保留，所以“删除”并非指全部删除

基于第二点，因为可以单独修改某一条，修改的时候如果这条数据写错了格式，可能影响后一条读取，因为是字节顺序

如果你整个过程只经过一个 APP，传送的可以忽略，传送软件不会无聊到隐秘改 exif，那就可以怪这个 APP，这点跟你说的完全不矛盾

拍照漏掉几条关键记录，是比较奇怪的，我倾向是拍照 APP 内部自带修图模块，这个修图模块把 exif 数据写差了
因为拍照+修图一气呵成，操作者无感，以为只有拍照模块

看完了，说些个人看法

程序员写博客，应该说明文占了绝大多数比例，论文其次，其他文体除非有个人爱好不然比例很小
说明文主旨明确这个就不用说了，是必须的，在易读性方面比较重要的是说明顺序

LZ 此文建议“总分总”，但其实还有很多其他顺序可用
程序员的话，可以把写文章顺序想象成一个代码的设计模式
抽象类、接口就是前言、index
如果写一次出错及解决，就是单例
如果写安装过程，工厂模式，1234 怎么做
如果写项目的架构，建造者模式 /责任链模式，1234 各实施什么职责
如果写权限分析，适配者模式，就不要 1234 而是圆点列表
……

当然，正如 “设计模式不是固定的” 那样，写作顺序也不是唯一，同一个问题，切入点不同顺序也可以多样

见过一些文章非常详细记录了自己的纠错过程，这些文章适合自己（备忘录），但不太适合别人
大多数人不太关心笔者走过的弯路，简略带过指出“此路不通”或者“治标不治本”就行了，正确解决方案最重要
当然不排除少数人很有耐心看完全过程，这些往往是探究中间弯路为何不通的人，如果确实想全记录，建议把最后正确处理的步骤加粗显示，有点像前置;TLDR 的意味

@swieer #15
指南通常是“正向引导”，指北是“逆向引导”
逆向不是引导错误的意思，而是指出错误达到引导正确的目的，意思就是纠正、勘误
如果换一种现在常见的说法就是《程序员的中文写作的误区》

还没看文章，不知道是否这个，但指北是这个意思

1.凡是要打字的都都很难
2.绑卡你帮她做吧，让她记住支付密码就好了
3.扫码也很难，我老妈每次微信挂号都是交给护士操作，连支付密码也告诉护士……所以我帮她绑二类卡，里面很少钱
4.日历等等因为打字，见 1

建议还是教她用“犀利”

vscode 是异步读取的吧？

exif 一般只是软件问题，图像才跟硬件有关

然后产生问题的可能性太多，但归结就是三点：
1.拍照的 app 没设定记录 exif 相关信息（例如出于隐私保护）
2.后处理的 app 去掉了 exif
3.有 exif，但可能出错或者其他原因没显示出来。例如 exif 格式不对

可以通过替换法看看是否内置 APP 的问题

1.不上框架很容易学
2.上框架不知道学哪个，其实后端遇到多个功能相同的三方框架也难选，但后端们互相有反馈，还能选一下，前端的反馈看不懂就没法选了
3.排版是个问题，如果只有横或竖是简单的，一旦多个组件组合，流式还是固定……
4.排版影响定位
4-1.为何连字体、字号不同都影响定位❓❓❓
5.事件驱动，但事件太多，例如一个小小的输入框，可能有 on keypress, on finished, onclick, on mouse over, drag & drop, on focus ... 十多个事件，后端一般只考虑数据，个个控件都考虑一遍全部 event，太累
不过，如果学过前端，就知道几乎所有控件来来去去都是那几个 event……控件独有的 event 其实不多，用到才去研究就行
6.前端数据格式，无论初始如何，最后是字符 /字节输出（且要考虑格式漂亮），后端只是传数据
7.前端数据安全和后端数据安全，概念和处理完全不同

A.前端几乎没有 try/catch …… 任何显示错误都是 bug
B.老板会对前端指手划脚，对后端甚少

其他还没想到

@sagaxu #9
应该没那么多吧，现在负责泊车的有那么高收入吗？

你的描述不对，不是本机所有数据，而是这个 profile 相关数据，其他 profile 还在的
我就长期三个 profile 共存，一个翻一个不翻，还有个不登录很少扩展比较干净的

你没选择同步书签和密码？你没选的话自然就要有这个思想准备啊
另外，本地 profile 目录也是应该定期备份的，不能完全依赖 google，万一梯子出问题，本地又要做恢复呢

教你一个港式粤语词：着草

去抢阿三的工作 —— 客服
🐶

或者客服的对面，不是很多人出现美区帐号问题，又搞不定客服吗？
也是 🐶

@JackCui #11
没去看或者说看不懂代码
如果 sdk 的步骤分得比较细，可以重写后处理（模糊）的模块，变成伪造数据（不一定是整体换脸），这就很多可以玩的功能了

十多年没有追歌，或者主动听歌，大部分都是先听到翻唱，觉得好听再去听原唱，然后发现不怎么样或者不是我喜欢的类型
契合主题，近几年最印象深刻是《阿刁》，但风格完全不同，两者不能比较，其实更重要是这首歌打破了我对张韶涵认知的固有模式，重新认识了她

无关用什么系统，或管理系统
不是经常写入的文件，应该先整理，放到固定路径，仓库式保存
没事不要全都同步，应该习惯只同步最新的，已经入仓库的还同步什么，现在这年头还怕重复浪费空间？
定期（例如半年），把仓库再整理一遍就够了，那时候才去做去重的工作

管理系统更多应该考虑资讯管理（某路径关联的信息的增删改查），读写等等交给更专业的文件管理工具

你那些“雄心壮志”，看上去是自己，但实际都是别人的，什么大事业，其实要“别人的大事业”得到认可了，你才被认可
所以不是自己的

立 flag 不能立大旗帜，否则自己就要扛大旗，不累那就肯定要抛出异常了
先立自身的小 flag，后面就顺畅了

“小目标：先赚他一个亿……”，🐶

广东电信 299 是 500M 的融合套餐，地方不能高于这个价格，所以深圳 269 也是这个吧
你选便宜点 100M 就好了，注意中间的套路，例如副卡要 10/月，每个都默认开了彩铃 5/月（要自己取消），返还多少，我这里返还到翼支付的券是只有 3 个月限期，忘了充值就没了
399 初装有点离谱

最后你一定要搞清楚是不是一些小“营业厅”的报价，那些其实是经销商，不是正式电信的厅（线路是电信的）
特别是打电话来推销的，基本都是经销商
和他们签约，一切正常还好说，出问题的话，就算你去正式的电信营业厅，也会出现双方扯皮的状况，正式的营业厅办理的话，扯皮就不多，但当然价格就是官价了