实现都一个版本的 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 线的问题，因为之前的华硕路由连接没问题，一开始就没怀疑到线上面

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

如果 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 家庭作为一个整体的财务情况，而不会去计较谁的账号钱多，谁的账号钱少。

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

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