方法四，加一个命令行参数，用于指定从哪里读取配置文件。默认是从项目内部路径，可以指定覆盖。服务器上部署时，就在 systemd unit 或者其它启动机制里指定。

我自己做的小项目或者要供应商做的大项目里主要用方法三和四。

只写过业务代码没在生产环境玩过服务器运维但是对这个问题又困惑并且愿意较真的小盆友们还是认真玩玩服务器。比如用 Linux 的，至少了解文件系统的各部分，知道发行版打包好的基础软件是怎么使用文件系统里不同目录结构的，File-system Hierarchy Standard 是什么。虽然发行版打包好的基础软件的惯例通常不太适合 100%照搬到业务系统上，但有很大的借鉴价值，会让你们的系统部署跟运维老司机的对接更流畅。

只写过业务代码，没在生产环境玩过服务器运维的小盆友（也不排除有很多老手甚至所谓架构师）可能潜意识里默认认为配置文件“只能”或者“应该”从项目路径结构（当前目录或者下面的子目录）读取，所以在这个问题上会犯难。其实哪有这么愁呢？
方法一，程序里指定从 /etc/<my_project>/<some_item>.conf 这样的 site-wide global path 里读取配置，开发机和生产环境各写各的配置，互不影响，提交的代码里根本不包含配置文件，而且做部署的时候也不会覆盖现有的配置文件。缺点是如果配置文件语法、语义有版本变化，需要生产环境的运维人员配合做升级。
方法二，做两个不同的 profile ，但都是从项目内部路径读取配置。开发机用开发的 profile ，部署到生产环境用生产的 profile 构建打包。两个 profile 的配置文件加入.gitignore 确保不会提交。缺点是每次在新的开发机上 clone 出来需要自己准备配置文件。
方法三，做两个不同的 profile 。开发机用开发的 profile ，从项目内部路径读取配置。部署到生产环境用生产的 profile 构建打包，不打入配置文件，而是从 site-wide global path 里读取配置。开发 profile 的配置文件加入.gitignore 确保不会提交（其实提交了也无所谓）。集一和二的部分优缺点。
当然，做不同 profile 也有多种实现方式。一般 Java 项目是在构建时区分，某些脚本语言的项目往往在运行时通过读取环境变量或者命令行参数来区分。只要能分开，都不是大问题。

用窗口函数

诸君哭到天明也哭不死董卓

@A01514035 短期关掉测试一下看是不是运营商从 ipv6 栈推过来，又不会怀孕的。

关掉 ipv6 看看

什么类型不类型的，C 又不是 Haskell

举个栗子：过程 A ，从界面获取用户输入；过程 B ，检查用户输入的格式正确性；过程 C ，拿用户输入调用后端业务。
业务逻辑是按顺序调用 A 、B 、C 。

过程 B 里判断输入格式是否正确，用 if ，因为不对的格式是用户输入的，程序不可控，遇到了不是程序的错。

过程 C 里要再检查一遍用 assert ，因为这里数据不是直接来自不可控的用户输入，这是程序员可控的环节，格式再不对就是 B 写错了，写对的程序执行到这里不应该有不对的数据。

建议用云服务商的建站系统，不要自己装平台做配置和定制。理由：网站上线以后，如果服务器配置有安全问题、用的 CMS 平台有安全问题，你还要不要继续帮他维护？继续做，拖死你；不维护，坑死他。

看到"你不要站在 PG 的角度去看问题"，第一反应是我们用 PostgreSQL 的又招谁惹谁了……

你有没有想过，国内的很多人是在移动互联网时代才真正上网的，只知道没欠费停机的 SIM 卡插入手机后就能上抖音直播。TA 们从来没用过任何一家公共的或者机构的 Wi-Fi 服务，更没有想过在自己家里装 Wi-Fi 热点。对 TA 们来说，用 Wi-Fi 是超纲操作。TA 们遇到信号不好当然也是只会去运营商投诉。

不拼接

@nomagick 太毒了，怕不是硅基人派来的卧底

健康码

“都说 4K 屏细腻”，指的是同物理尺寸跟 1080p 、2560p 相比好不好，跟 5K 比当然粗糙了。粗和细是比较出来的，不是绝对数量。

要分清以注释面貌出现、给 external caller 看的文档，和不做为文档、给 internal maintainer / reviewer 看的真正注释