@chaleaochexist 关于二次封装接口这事，其实对我这样的小团队来说怎么看都是 import 更划得来，大家都用 PHP，为啥想不开要给自己对自己用接口调用，但这事我还是坚持接口化。就我这边来说，接口化不会带来多少性能损失，却给我这样的小团队和外部合作留下了足够好的基础（我们经常有交叉形式的外包），甚至某些接口我们作为收费卖给隔壁同行们……

当然这里面我还有个出发点，是为了三年战略中，逐渐引入 Java 或者 Go 开发人员和目前的 PHP 栈混用，这时候通过接口通信的模块化意义就更大了，这是和我司实际情况有关。

所以你想学的是后端语言对吧？

语言好像不是差别很大，除非还想做单体应用，如果为以后考虑，Java 和 Go 都可以考虑下。

首先，实际页面存在多设备兼容这个问题，除非 UI 全给做到，否则 100% 还原度就没法做到。

我们现在暂时提倡的方法是不追求字面意义的 100%还原，而是由 UI 给出对元素兼具，字体大小等等的要求，详细到 font-size，元素在不同界面尺寸下的不同间距，然后前端只管照这个来堆上去。

既然是想深造，选个自己有基础有兴趣愿意攻关的，然后放心大胆的学吧。


我自己是大学本科，上一半跑路退学，现在三十多岁，然后现在从成人高考开始重新开始学习，选的不是自己现在做的开发和计算机有关的方向，但有我多年工作经验加成，我也有兴趣，希望四十岁的时候能小有所成。

实际操作中我们是这样。

一，有一组粒度极细，原子化的基础接口。

二，一部分常用的业务接口，对基础接口做二次封装。能满足 70% 的调用需求。

三，有 10%左右的需求因为目标简单明确，直接去了第一条里提的那些接口。

四，有一些临时项目需求，临时拼装一些小接口。

所以像你说的问题，我是绝对会拆出一堆各种 API 来的。

业务千变万化，所以我是要什么给什么，能拆分的 API 绝对拆开，不怕接口多，就怕接口改。改起来才是真要命，千丝万缕在一起。

业务 API 因为太多，所以时间久了会有重复功能的接口，我也毫不在意，因为这类接口只直接为一个业务服务，业务哪天变了或者撤了，老的接口也就没用了。

能，有变通方法，但不好用。

而且似乎也没必要这么用。

不是我喷，画像这个东西技术层面大家各有做法，但有没有可能，在现行的一些系统下这压根就是个不存在的东西。

很多人，喜欢一类事物，但希望有人推荐介绍给他其他类别的事物，不管喜欢不喜欢，在很多时候，我们喜欢尝试不一样的东西。

我总感觉，推荐系统做到最后，很多时候就是随机给。

非要说什么地方可以精确确认，那不是我不喜欢，而是明确强烈的『我不喜欢』，当用户表现出强烈的反感时，系统收敛点，不给推荐这类内容，那就是推荐系统善莫大焉了。

刨除掉不喜欢的，剩下的，random （）吧。

我最近在一个做的系统里用了一个古早的方法。（当然我以前不知道，或者是用的太少忘了。）

<div data-include="header" class="headerBox"></div>

然后 js 部分

<!--下面的 js 用于引入模板文件-->
<script>
$(function() {
var includes = $('[data-include]');
jQuery.each(includes, function() {
var file = 'views/' + $(this).data('include') + '.html';
$(this).load(file);
});
});
</script>

模板文件路径为 views/header.html

可参考。

这个方法其实不是真正的组件化，但遇到 JS 做处理的时候，其实会有不少问题。
但如果只出静态页面，就要你写个样子出来的话，JS 主要处理一些 DOM 的话，这个方法能节省不少劳力。
又避免 iFrame 的一些问题。

风扇大？

我用 Chrome 来访问……

@wangxiaoaer 同不熟悉，毫无基础。

但我想明白了这么两件事。（至少我自以为想明白了）

1 不管你怎么个 API 网关，用什么语言写，用什么控制，对我这样的小公司，在最前端这件事上，找不到任何比 Nginx 还要靠谱和适合我的工具了。 对，我是可以直接拿应用顶上去，要什么 Nginx，反正我们流量也不大……但我不敢，也不想。

2 Lua 我一点都不熟悉，但分析之后觉得我在这个层面上，并不需要让 Nginx 负责太多的逻辑，对我而言我更需要的是 Lua 给我实现接口，我可以由其他工具把我要的 Nginx 配置规则给塞过去并加载。我觉得从这个层面而言，并不需要我有太强的 Lua 方面的知识储备……

就……艺不高人也胆大吧……

@wangxiaoaer 对，本质上肯定会有逻辑处理。不过我是参考了若干大公司的方案后，然后……全部抛开。

小公司，小项目，不需要还搞专门的服务配置和注册中心。

裸 nginx 先上了看看好不好再说。

@wangxiaoaer 目前我这只是第一步，先做一个拆分，把路由层和应用分开。

之后会考虑用 lua 进行对 nginx 的控制，有一个专门的应用用于将后端的限流控制等注入进 nginx。

我们现在的 api 也还是直接 laravel 走起。
但已经在前面的 nginx 层开始做一些处理了，今后会把 nginx 作为 api.example.com 的直接输出，后端再具体分发到不同的后端服务去。

版本的话处理方法很多的，但我还是倾向于把版本处理交给更后层处理而不是集中在前面。
因为我的理解中，除了授权等控制行为外，API 网关还有个重要的事是第一层路由。
我个人目前工作中是试图把 API 网关作为纯路由，至于那种控制和集中处理的事应该由另外一个配置中心来处理，对 API 网关进行操作。

朋友们，你们有没有想过，在中国大多数公司的现实情况下，有的时候编译慢是好事？

对，我就指磨洋工。

当项目经理非要把 7 天的工作量压到 2 天完成的时候，编译慢是你最好的武器。



当然我不建议这么干，但有的时候，某些情况下，这是我怼人的武器。

可以。

人总是要休息下的，这宝贵的几秒钟很重要。

这个小程序比上一版好看多了。

巨龙满意了。