实现都一个版本的 Pop 不就好了……

func (stack *Stack) MustPop() int {
value, err := stack.Pop()
if err != nil {
panic(err)
}
return value
}

如果有可能产生 err ，那么一定是要返回并检查 err 的；
如果不可能产生 err ，那么就实现一个不返回 err 的版本。

err 的真正槽点在于，当调用链比较深时，每一层都需要判断 err ，return err……

@zhtyytg 话不投机不要说不就完了嘛？非要说那么多干嘛呢？我是不是可以学你这么说：

既然复制粘贴这么牛逼，你也掌握了这个大招，在前端圈应该混得风生水起，财富自由了吧？相反，我由于没理解到复制粘贴的精髓，所以混了这么多年，还在苦哈哈打着工，有上顿没下顿的。是否有什么书讲解这个技巧的，不凡告知小弟，我想学习一下，

@finalwave 我觉得这是另一个问题，不能因为别人烂我跟着烂吧……实际上，好的设计适应性也强，更不会因为产品设计的调整就大动干戈。

@fuyun 虽然我也不用 vue ，也更喜欢 react 的设计理念，但是我不认为 vue 就不配谈设计模式。其实，再烂的语言，都有漂亮的写法。前端项目短平快是现状，现状不意味着正确。

@zhtyytg 其实问题是出在人的能力上，能力已经具备的前提下，高度封装是本能，肯定是比简单复制粘贴高效的。但是很多人把能力建设的时间算在项目排期上，因为他不会，而学习需要时间，但学习其实是在学校阶段就要做的事情。

居然都说复制粘贴好，前端都这个水平吗……

拿我们的前端来说，同个东西，在不同页面都有不同的风格和行为，不就是因为复制粘贴来的吗……一个设计良好的系统，好多通用改动，本来在框架或者模板层面动一下就解决了。结果因为复制粘贴多了，改动扩散到好好多个页面，然后 TMD 还改漏了……

设计模式是个好东西，结果因为自己驾驭不了就说复制粘贴好，就没人怀疑过自己的认知吗……

@james19820515 线的问题，因为之前的华硕路由连接没问题，一开始就没怀疑到线上面

配个域名白名单，先实现内网 url ，这样对 CEO 就有交代了；
然后把外网可能涉及的风险提出来，让 CEO 拍板；
CEO 同意就让运维调整配置，去掉白名单控制；
这样操作下来还跟写代码的有半毛钱关系？

程序配置化，文档注释充分揭示风险，至于别人想怎么配，怎么用，那是别人的事

如果是你开公司，你应该不会招一个技术比较菜的，然后上班带薪学习吧

如果 https 能被破解，那么你前端 hash 后传输也没什么鸟用，拿到你的 hash 还不照样黑你？如果 https 不能破解，我传明文又怎样，你还不是拿不到？

换句话讲，在传输过程中，数据安全是由 TLS 加密链接来保证的。当然了，在数据库存储时，必须加盐 hash 或采用其他可靠的加密手段，禁止明文。

这个行为很正常啊，指针或引用类型的数据都是这样的

有空可以了解一下语言的内部机制，你就会本能地避开某些机制性的坑，比如 Python 对象模型可以参考这个：

https://fasionchan.com/python-source/object-model/overview

刚买了一双户外溯溪鞋，面料是防水的，还没实际测试过。不过在水龙头下冲了几次，确实没湿，找个雨天实战一下。

主机和路由的工作流程都一样：

1. 从 IP 包中取出目的地址，然后查询路由表，看下一跳的地址 N 是什么？
2. 接下来，通过数据链路层，把 IP 包发给下一跳 N ，步骤如下：
- 执行 ARP 协议，查询下一跳 N 的 mac 地址；
- 封装数据链路层帧，将 IP 包发给下一跳，目的 mac 地址是上一步通过 ARP 协议查询到的。

具体可以参考这篇文章： https://fasionchan.com/network/ip/routing/

@ivvei #88 咱不杆哈

①部分修改那里，我把 Method 打错了，应该是 PATCH
②我不知道前面那里那个地方五花八门了。拿我们自定义的 action 部分来说，我们至少保障 action 是一致的，想搜索数据就调_search 接口，比如：

- POST /Datas/_search
- POST /Hosts/_search
- POST /BusinessSystems/_search

再比如，我们所有软删除数据接口，action 都是_markDeleted ，不会 A 叫 softDelete ，B 叫 softRemove

- POST /Datas/{id}/_markDeleted
- POST /Hosts/{id}/_markDeleted
- POST /BusinessSystems/{id}/_markDeleted

/some/resource/path 只是想表达有些 action 是在数据集上，比如/Datas ；有些 action 是在单个数据记录上，比如/Datas/{id}；甚至有些 action 是在子数据上，比如/Datas/{id}/SubDatas/{subid}。

哪里五花八门了？

你不会看到/some/resource/path 跟/Datas 不一样就觉得五花八门吧……

我通篇都在强调统一一致的范式，而不是在强调就应该采用跟我一样的思路。我不在乎范式是什么，我反对前后不一致，没有任何规则的 POST 而已。

“不要说别人就五花八门，说自己就是合理约定。”你这么说不就想说别人双标嘛……还真不是……

今天想起要回这个贴，是因为上周我手下的人刚别其他项目的接口坑了一下。他们告诉我的人，要换个接口，返回的数据字段没变。我的人就去换了，因为对方说接口一样，数据字段没变，他们就偷懒没验证。结果上生产就出了个小问题，因为数据有个字段结构不太一样……

同一个字段，有一个接口是返回逗号分隔的字符串，另一个返回一个字符数组……理论上，同一种数据，不同的查询场景，返回的数据字段结构没必要不一样吧？这才是我强调的五花八门。

然后，我在自己项目的开发群里强调了范式规范，不知怎么发图片，直接贴我说的文字：

理论上，接口再垃圾，只要我们验证充分，问题肯定不会到生产上。
就算接口不好，最多也只是在开发阶段被坑，影响你的研发效率而已。
冤有头，债有主，谁坑你就去怼谁。
我以前经常跟你们强调，字段命名要前后一致，严禁五花八门，最近几次缺陷就是典型的案例。质疑别人前，我们自己要先做到这一点。

注意看， [质疑别人前，我们自己要先做到这一点。] 我们对自己的水平心里有数。

大家是不是对 Restful 有什么误解，Restful 多出来好几种 method ，是 GET/POST 的超集，不存在能力比 GET/POST 更弱吧？

我维护的项目，采用 Restful 协议，迭代了好多年，没发现有什么坑啊

比如，一个资源普通的增删改，能有什么问题？

POST /Datas # 新增
GET /Datas/{id} # 查询
PUT /Datas/{id} # 修改（整体替换）
PUT /Datas/{id} # 修改（部分更新）
DELETE /Datas/{id} # 删除

对于特殊的业务逻辑，我们约定好一个在某个资源上做的一个动作，范式如下：
POST /some/resource/path/_action

举个例子，我们想让数据支持软删除：
POST /Datas/{id}/_markDeleted # 软删除（打标记但数据不删）

再举个例子，搜索数据集合，Body 传一个 Filter （比如 Name 符合某个正则表达式）：
POST /Datas/_search

{
"Filter": {
"Name": {
"$regex": "abc"
}
}
}

最后一个例子，某条数据记录想发一条通知出来：
POST /Datas/{id}/_notify

迭代了这么多年，没发现有什么所谓的业务逻辑套不进去的问题啊。

还看到一个说法说，Restful 需要写好多个接口，然后再让前端来整合？这不是典型的接口 [粒度] 问题嘛……

站在后端的角度，接口粒度合理拆细是可以，难不成来个场景你加个接口刷一刷存在感吗？别人我不知道，我对手下的后端的要求就是合理地细，让前端可以灵活组合完成特定、个性化的业务场景。

站在项目统筹管理的角度，如有某种组合很常用，你让前端自己一遍遍地去拼接也不合理吧？这个时候不就提供一种粒度更粗，但更固化的接口出来吗？这样双方不都得到满足吗？同样别人我不知道，我对手下的前端的要求，就是接口不合理，需要不断重复组合的逻辑，就要反馈给后端。然后一起消除重复性。

总结：①后端接口粒度在合理的前提下，尽量细；②对于常用组合，再封装更固化和个性化的粗粒度接口。

还有一个问题，说前端框架封死了只能 GET/POST……挖槽，前端垃圾关你啥事？关 Restful 啥事？能 diss 他就 diss 他，不能 diss 他的就捏着鼻子接受吧。

还有人提到，说客户公司只允许用 GET/POST ，怎么说呢？都做乙方了，当然没办法了，甲方说啥就是啥……但这是你还是有办法在 POST 方法的基础上，自行定义一套给 Restful 类似的协议，无法是把原本用 Method 来表达的信息搬到 body 里而已。举个例子：

POST /Datas/{id}

{
"Action": "UPDATE",
"Data": ……
}


因此，重点不是 Restful or GET/POST ，重点是接口要满足一套统一而且规范的范式。

我同意有人提到说 GET 、POST 是负责人不负责任的做法。就 POST 请求，然后 path 爱怎么定就怎么定，数据爱怎么传就怎么传，最终一定是座代码屎山。举个例子，我合作过的项目，就纯 POST 的，但接口五花八门。同一种数据，不同接口返回的格式有些字段名还不太一样，一不留神就被坑到。这就是垃圾。被坑的次数多了，别人就会抗拒跟他合作。

据我的观察，绝大部分程序员，特别是外包根本就没有驾驭抽象范式的能力。没能力也就算了，不少人还喜欢浮于表面，夸夸其谈。说到底，“无规则不成方圆”，这么简单的道理，我们几千年前的老祖宗都懂。但不少所谓的新时代开发工程师，还在重复着开发一个垃圾接口，再写一份垃圾文档来描述这个垃圾接口的死路。

https://fasionchan.com/network/ 几年前写的，又有段时间没写了……

真正信任对方的人，其实谁管都无所谓。

我们家目前就是这种状态，两个人各管一部分，投资渠道也差不多，大额存单和指数基金定投。她没提过要管钱，我也没提过要管钱。平时也会互相转来转去，比如要凑钱买另一种大额存单的时候。

然后我们共同维护了一个在线表格，统计各种账号的余额和负债情况。每个月 1 号都会一起花半个小时更新这张表格，表格自动统计出上个月的收支情况。没有可以要管理所有钱，但全家有多少钱，分别分布在什么账户上都是公开的。我们 care 家庭作为一个整体的财务情况，而不会去计较谁的账号钱多，谁的账号钱少。

我觉得这种状态挺好的，可以参考一下。

重点不是钱谁来管，而是钱的管理过程公开透明，而且双方的指导思想要一致。举个例子，一个人花钱大手大脚，一个人守财如命，多半还是会有很多矛盾的。因此，归根到底，还是要找到三观一致的人结婚，亦或者尽量磨合。