求知若渴，虚心若愚！
居安思危，积极进取！
最近看到一个问题："全栈工程师是不是什么都要会？"下面的回答分成了两派，一派说全栈就是要前端后端数据库运维都精通，另一派说全栈是个伪概念，啥都会等于啥都不精。
两边都有道理，但我觉得都错了重点。
做了很多年全栈，从后端写到前端，再到带团队做架构，我的观察是：大部分人误解了全栈工程师的核心价值。全栈不是让你成为技术全才，而是给你一个完整的视角去理解系统、做决策、解决问题。
追求全能是个陷阱，追求全局观才是正道。
全能是个伪命题
先说个真实场景。
在金融业务中，经常会遇到性能问题。前端说页面慢是因为接口慢，后端说接口慢是因为前端请求太多，DBA说数据库压力大是因为查询写得烂，运维说服务器资源不够要扩容。
这时候如果你是个"全能型"全栈，你会怎么做？去优化前端的渲染逻辑、重写后端的查询语句、调整数据库索引、然后去研究服务器配置？
听起来很厉害，但实际上这是在用战术上的勤奋掩盖战略上的懒惰。
真正的问题可能是：这个需求本身就不合理，或者整个架构设计有问题。
前几天团队来了个新人，看到我们的CR流程后很兴奋："你们的Code Review好规范啊，每个PR都要两个Approver才能合并。"我笑了笑没说话。
因为我知道，这套看起来"规范"的流程，实际上每天都在发生这样的事情：开发者提交一个几百行的PR，半天没人review；着急上线就去钉钉群里@几个人；被@的人打开看一眼，觉得代码没大问题就点了Approve；测试环境跑了一遍没报错，代码就合并了。
整个过程看起来很严谨，实际上谁也不知道这段代码到底干了什么。
大多数CR都是形式主义
我见过太多团队把Code Review当成一种"仪式感"——必须要有这个环节，但没人在乎它到底有没有效果。
最常见的场景是：PR提交后，reviewer们象征性地打开看一眼，扫过去没发现明显的bug或者格式问题，就点了Approve。至于这段代码的设计是否合理、是否有更好的实现方式、是否会给系统带来潜在风险，没人去深究。
为什么会这样？因为review代码比写代码累。
最近看到团队在讨论页面首屏加载优化，有人提出要把某个 10KB 的图片压缩到 8KB，说能省 20% 的体积。我突然意识到，前端性能优化可能是我见过的最容易被过度执行、也最容易做错方向的技术工作。
不是说性能优化不重要，而是大部分人根本不知道自己在优化什么，也不知道这个优化到底值不值得。
性能优化的第一个迷思：技术指标不等于用户体验
打开任何一篇性能优化的文章，你都能看到一堆指标：LCP、FCP、TTI、FID、CLS。这些指标确实有价值，但问题是，你真的理解这些指标背后的含义吗？
我见过一个团队花了两周时间把 FCP 从 1.2 秒优化到 0.8 秒，但实际上首屏还是白屏，因为真正有意义的内容要等接口返回才能显示。用户看到的"快"，和监控平台上的数字，完全是两回事。
LCP 优化≠用户感知快。LCP 是"最大内容绘制"，但如果你的最大内容是一张无关紧要的背景图，优化它有什么意义？用户真正关心的是"我能不能看到商品价格"、"我能不能点击购买按钮"，而不是你的背景图加载了多快。
前端圈对状态管理的执念，可能是过去十年最大的集体焦虑。从Flux到Redux，从MobX到Recoil，从Context API到Zustand，每隔一两年就会冒出一个"更简洁"的方案，然后大家又开始新一轮的重构和争论。
但我越来越怀疑一件事：我们在用前端的方式解决本不该存在的前端问题。
状态管理焦虑的根源
大部分前端开发者第一次接触Redux的时候，都会有类似的困惑：为什么一个简单的计数器需要写这么多代码？action、reducer、dispatch、connect，整整一套ceremony，就为了让组件拿到一个数字。
当时流行的解释是："这是为了可维护性。" 等项目大了你就懂了。
确实，等项目大了，我懂了。但我懂的不是Redux的好处，而是我们把太多不该放在前端的状态放在了前端。
举个真实场景：用户的投资组合数据。
前两天团队讨论新业务的技术方案,后端同学提议用 GraphQL,理由是"前端可以自己控制数据结构,不用频繁改接口"。我问了一句:"你们后端有多少人?"答:"3个人"。我说:"那别折腾了,RESTful 就够了"。
这不是第一次遇到这种情况。这些年做全栈,从后端写 API 到前端调 API 再到 BFF 层设计 API,见过太多技术选型上的执念。最常见的两个误区:一是觉得 RESTful 就是正统,必须符合所有规范;二是觉得 GraphQL 能解决前后端协作的所有问题。
事实上,这两个都不是银弹。
RESTful 的形式主义陷阱
大部分开发者第一次接触 API 设计,学的都是 RESTful 规范。GET 查询、POST 创建、PUT 更新、DELETE 删除,资源路径用名词不用动词,状态码要严格遵循 HTTP 标准。这些原则没错,但问题在于,很多人把它当成了教条。
前后端分离已经是前端圈的"政治正确"了。但最近几年，我观察到一个反常识的现象：不少团队在推进前后端分离几年后，又开始招聘全栈工程师，甚至把部分项目重新合并。
这不是技术倒退，而是对"分离成本"的重新认识。
前后端分离的三大隐形成本
大部分团队谈前后端分离时，强调的是"职责清晰"、"技术栈解耦"、"并行开发"。但很少有人提它的代价。
1. 沟通成本：从「对话」变成「会议」
以前一个功能，全栈工程师自己从前端写到数据库，遇到问题自己调试，半天搞定。
前后端分离后？先写需求文档，前后端对齐接口，联调发现参数不对，再开个会讨论，改完继续联调。原本半天的事，拉长成三天。
我不是说会议不重要，而是很多"会议"本质上是在弥补"认知鸿沟"——前端不知道后端为什么这么设计，后端不知道前端要什么。
金融业务尤其明显。理财产品的持仓逻辑，涉及到实时资产、历史收益、预期收益三种数据，前端需要合并展示。如果后端不理解前端的渲染逻辑，可能会返回三个接口；前端不理解后端的数据模型，可能会要求合并成一个接口但无法满足缓存策略。
这不是技术问题，是认知问题。
参考：https://hub.docker.com/_/mysql
官方文档是这样写的：
$ docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:tag
其中 some-mysql 是你想要的mysql容器名， my-secret-pw 是mysql的密码（用户名是root），tag MySQL 版本，没有的话默认是用最新的latest版本。
本地启动mysql容器可以参考：https://blog.csdn.net/weixin_44037416/article/details/117956869
博客是放在Amazon的EC2.
全程参考：http://imcn.me/html/y2012/11870.html
其中遇到文件权限的问题：
默认EC2的nginx和php-fpm的用户和用户组是www-data。但是我ubuntu的文件权限是quentin，所以php写文件没权限了。
所以为了使php-fpm和文件权限一致，配置如下：
修改php-fpm配置：sudo vi /etc/php5/fpm/pool.d/www.conf
user = www-data 改成 user = ubuntu
修改nginx配置：sudo vi /etc/nginx/nginx.conf
user www-data 改成 user ubuntu
最近遇到一个低级问题，希望可以帮助跟我一样的同学：
问题描述：
本地环境是XAMPP，内置MySQL以前是好的，好久没用了，最近启动MySQL时提示如下错误：
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/Applications/XAMPP/xamppfiles/var/mysql/mysql.sock'
当时我以为是本地MySQL出问题了。经过环境变量，权限等排查仍然找不到原因。
其中也试过了：locate mysql | grep sock
结果：/Applications/XAMPP/xamppfiles/include/mysql/psi/mysql_socket.h
也找不到mysql_socket.sock。
最终，发现其实mysql是好的，只是mysql.server没启。
执行下面命令即可：
sudo /Applications/XAMPP/xamppfiles/bin/mysql.server start
前言：
MySQL的备份/恢复(导入)命令一般使用如下：
备份：
mysqldump -uUSERNAME -pPASSWORD DBNAME > FILE_BACKUP.sql
恢复(导入)：
mysql -uUSERNAME -pPASSWORD DBNAME < FILE_BACKUP.sql
注：
这样就实现了备份和恢复。
乱码问题：
但是，如果你拿到一份别人或者从网上download下来的sql备份文件，导入之后发现有乱码，怎么办？
一般出现乱码是跟导入时的编码相关。其实很简单，导入或者备份时加一个参数（--default-character-set）就可以避免编码问题的发生。
如：
备份：