就是一个标准统一就好，我个人更喜欢驼峰。
虽然阿里巴巴的标准是全大写，并且目前我们项目领导也要求这样，我也遵守了这样的规范。

DTO 和 HTTP 、URL 、SQL 、NBA 、NASA 、API 、GUI 、REST 一样都是一类专有名词缩写，针对于驼峰命名法而言，我的理解是按照驼峰结构修改，和普通单词一样，按照驼峰方式拼写。
QueryUrl 、UpdateSql 、NbaList 、FakeApi 、Rest 、UserDto 、UserVo 。

而 DTO 、VO 、DAO 这类东西和前面其他专有名词缩写有一点不一样的地方在于它在名字中是存在特定编程含义的，而其他专有名词在技术层面没有任何意义。
NbaList 、CnCity 、这类缩写对于某个新加入项目的人而言与 AList 、BObject 并无区别理解代码改造代码的时候无需了解这个缩写的含义； DTO 和 VO 你看到他们的时候你就知道这个类的用途。

所以我可以理解为什么有人认为该保持全大写，但我个人更倾向于统一用驼峰，不能因为它表达的含义不同就专门例外。

前后端分离指的主要是渲染视图和数据分离， 不一定前端非得有专门的服务器。

比如完全可以直接生成静态的 html ，用户请求之前这个页面就已经生成完成， 然后由浏览器直接渲染这个完整的 html ，再执行 js ，通过 ajax 读取到数据 A ，再把数据也渲染出来。当用户访问其他页面的时候就是访问另外一个 html ，从页头到页脚都重新读取重新渲染不管一样不一样，然后再去读取另一个数据 B 。


但这样就出现了一个最主要的问题，当是搜索引擎爬虫访问或者用户网络不好的时候，他们只能看到一个空框架没有任何数据内容。
为了解决这个问题，所以才又专门准备一个渲染服务器，也就是你说的前端服务器，html 页不再是直接生成好的空框架页面了， 而是可以先读取空框架模版再由渲染服务器去访问后端服务器获取数据，然后生成包含数据的 html 页，这时候再返回给用户。

0 、GPL 不限制收费，只要你给源码，哪怕你直接拿开源软件就改个名字去卖一个亿都不违反 GPL 协议。


先说 web 项目和网站用户的问题，GPL 诞生的年代 Web 的形态和现在差得远呢，他们确实没有考虑到这种形式。所以你的网站如果只是提供服务，那么 GPL 的代码你在修改之后也不需要给谁，因为你只是在使用，没有“发布、分发”，所以自然不需要为你分发的客户提供源代码。 网站的用户只是通过某种协议访问了你提供的服务，但他们并没有你这个服务的所有权。

---------------
比如你拿一个 GPL 开源的 wordpress 插件修改成了一个在国内很优秀的功能，你自己搭建了一个网站大堆用户都用这个插件的功能，这时候你不需要给他们源码； 然后你选择售卖这个插件盈利，那么你有义务向购买了你程序的其他网站站长提供源代码。
----------------

我以为偏技术性的论坛对于服务器防护还会比较关注。

没想到大家安全防护意识这么低的么...

如果说向安全大佬一样，所有端口都采取白名单那确实不现实，毕竟很多时候我们访问自己服务器的出口 ip 不是固定的。
但不开放常用端口，常用协议不使用默认端口和不使用弱口令好像真的挺常识的....

@xiayushengfan mongodb ，我们用的也不是很有心得，我们还是按照关系型数据库的用法或者 k-v 缓存的用法在用。

比如我们如果用 mongodb 存站内信的话，就是一个集合是所有消息，或者一个集合是一个月的消息之类的维度，每个文档包含文档的全部内容包括所有的接受用户 id ，以及已读状态， 查询的时候 直接查当前用户 id 的文档数据。

@kaiki 最后我们是发多条了，没有组的概念，这种情况下按照你说的方式确实能优化一些存储。

针对后面的问题，我们的文章表有 n 多字段，对于消息来说都是完全没用的，而且文章没有记录多少人已读的。
最后我们的站内信不是用户给用户发送的，基本都是系统通知，"你订阅的 某个资源更新了，url " 类似这种，所以我们和楼主的也不完全相似，因为我们的消息大多数是分组的，个别是全站群发，没有用户间私信。

最后说说你的需求
1 、数据肯定要落库的，虽然这个数据重要性不高丢了就丢了，但发消息偶尔会出现收不到肯定最起码业务领导会不爽。
所以如果想要性能那就用搜索引擎 es 或者其他非关系数据库如 mongoDB ，数据读取层面还可以加 redis 。

2 ，3 、阅读很少那就把阅读单独建表， 就像我们那种， 阅读表包含消息 id 、用户 id 、是否已读、已读时间、创建时间啥的。

本来当时打算有个消息发送组的概念，消息分为发给个人还是发给某个组， 然后组里面有个魔法值是群发。
结果这个功能对于我们本事不是很重要，而且人手要优先干其他的，所以这里就简化了，有给某个组群发的需求，就 foreach ，创建多条信息发送给指定的人。

我先说个我之前设计的实现，不一定好，而且当时我们的在线用户量级很小都不担心这个问题。

一张用户表，一张站内信表，一张站内信已读表。

站内信表中有 sendUserId 字段 魔法值 0 代表发送给所有人，其他值代表只发给某人。
因为我们数据量不大，所以消息是直接 join 查的，order 排序未读的展示在前。

@GoodRui 那就改呗，其实不改也无所谓，有 ssh 密钥还知道生产内网数据库密码的就那么两三个人，而且离职率也不高，就你离职了然后公司的生产环境就被黑了那不是找死么...
我离职的时候是直接把我电脑格式化了，密钥和电脑里记密码的笔记都一起格式化了，我也不想知道。

我们的方案很粗糙很简单，除了主要几个人其他人不知道生产服务器密码，测试服务器密码就知道了。

生产配置文件不在 git 里存在 jenkins 里，
每次发版时候有权限那几个人肉眼核对配置文件的修改，然后去 jenkins 里修改对应生产配置文件。

是两个维度的定义，以电脑端 cpu 举例。

armv8 = intel 奔腾，i3, amd 速龙，Ryzen
arm64 = amd64(x86_64)

对，只有行人是没有强制的正逆行要求的，其他的车道都需要遵守靠右行驶的规则。

歪个题。

专升本是专科近邻毕业去考某个大学的本科专升本专业（但这考试难度不咋大），然后直接续上，接着上 2 年学。 总共 5 年。

自考，成考，那个不叫专升本，那是重新参加教育，你高中学历可以去考。

使用角度来说，java 中你可以直接死记硬背就好，简单的将 List<? extends Animal> 这种 ？号表示的泛型记成只读的集合。

从思考逻辑层面来理解如下三个方法：
1 、public List<Animal> getZoomAnimals () —— 获取动物园所有的动物
返回的结果指的是这个集合存放的就是 Animal 类型，Cat，Dog，Tiger 都算，都可以混着装在这里面。

2 、public List<? extends Animal> getSomeAreaAnimals(int AreaId) —— 获取动物园某个区域的动物
而这里就不是指的存放的是 Animal 类型的元素了，*他的类型就是确定的<?>类型*。
这个类型是什么？ 不知道，但可以肯定他，是 Animal 下面的*某一种具体的子类*，<?>类型如果是 Cat，那这个集合就不能存放 Dog 。这个<?>和匿名内部类一样，指的是某个具体但不知道名字子类类型，而不是父类的。

我在老虎洞里找到的一定全是老虎，而不会有犀牛；海底水族馆里也只会找到海洋动物，而不会把鹦鹉扔进去。


3 、public <T extends Animal> List<T> getSomeAreaAnimals(int AreaId，Class<T> cls)
与<?>相对的还有一个写法，如果我想让人操作返回的结果怎么办？答：你用的时候直接告诉我，“你知道我会返回什么具体的类型”。
这里实际与 <? extend Aniaml> 唯一的区别就是，你调用我的时候就已经知道 我会给你返回什么结果了， 当然也可能出现你以为的只是你以为，我会直接报错告诉你你给的类型不对。

你递给我一个鱼缸，让我去鱼类区给你抓鱼，我抓回来的一定是鱼，不会把猴子也塞里面； 你给我老虎笼子让我给你昆虫区抓蚊子，我只会告诉你你给错家伙事了。

分母+1

数据库三范式 和 xhtml 一样， 是一种追求严谨的设计思想，希望的是人类去匹配机器的结构，毕竟机器是死的所以要人去绝对优化尽量发挥 100%机器性能的。

这种思路希望一个东西从设计到开发全部都是绝对理性绝对归纳的，业务变化之后依旧不要破坏当前结构，而是要重新梳理重新归纳，修改为新的绝对严谨规范的设计进行重构。

然而现实就是人都是懒的，而且科技发展使得计算机成本降低，技术的门槛也降到了大多数人都可以掌握了，但普罗大众的平均技术水平并无法与计算机新兴时期的顶尖行业精英群体比较，对极致性能利用的追求也逐渐优先级低于了对开发便利性的需求，所以 html5 和数据冗余干掉了 xhtml 和各种数据库范式。

发出去之后我突然理解楼主的想法了....

楼主以为 openid 有个大列表， 就个网址短链接一样，一个 id 对应一个值，不论是啥数据都从这查。


然而实际上， 这种 id，生成的服务只管生成，生成的值有没有地方用到对这个服务都无所谓，也没有一个大列表记录每个 openid 对应啥。

我公众号需要用到一个 id， 那我就获取 /生成一个，存我这个表里， 他小程序要用到一个 id，那他就生成一个，存他那，支付用到了支付那边自己再存一个。

不用 openid 用数字自增这功能都不会出安全问题，
我公众号生成了 id=1， 他小程序生成 id=21，你在我这公众号里用 21 查能找到啥？
即便我公众号的表里有个 id=2 的，你查的时候我又不是不判断这个 id 是不是你能看的。

看起来楼主好像不是搞后端的啊，甚至好像不是搞技术的。
几个部分，
1 、你的固定生成和通过微信 id 算出来，实际想表达的是不是“生成 id 是否与与用户或其他业务数据相关？”。
答：无
与业务数据肯定是无关，因为没意义，但大概率与时间有关，给你两个 id，你可以知道这两个 id 哪个生成的更早，仅此而已。
这世界上有许许多多的随机数生成方法，包括算法层面的伪随机(一般常用)，和真正意义上的随机(利用硬件电荷，效率慢，非特殊情况没人用)。

现在常见的各种随机字符串生成方案大多数都是根据 推特公布的雪花 id 生成规则的思路制作的，估计微信很可能也不例外。

2 、和其他数据存数据库没什么差距，数据库 io 写入瓶颈了就升配置或者加机器，查询慢了加缓存。

3 、你知道了规则有什么用， 身份证规则百度就有，但你随便生成一个去银行或者公安局人家又不是查不出来。
而且这种随机 id 生成会给许多不同的地方用，第一个用在用户 1 关注公众号 a，第二个用在用户 1 使用小程序 b，你用 A 公众号知道了 openid 又怎样，你公众号的关联数据里又查不到。