@yibo2018
你杜比音效明显是因为他的声源在不停的变化，所以你听着有立体感。
普通音乐制作各个乐器的位置都是固定的，立体感自然会比录音室里制作的音乐要强。
虽然杜比全景声的声音来源位置固定，但是他也是有层次感的。
你想让整个音乐以钢琴声为主，那么采用杜比方案可以把钢琴音源拉的近一点，其他乐器远一点。这样的听感就是钢琴在前，其他乐器在后，而非传统音乐里简单拉高钢琴声音。

声音空间感是一种比较微妙的东西。
你拿着手机播放音乐，然后将手机不停往前往后移动，能感觉出声音在向你靠近或者原理。但是如果你只是调整音量大小，这种感觉就不那么强烈了。

如果你是在还是听不出来感觉，那我建议是换耳机。
我手上有大馒头 2，1000xm3，airpods pro，杜比全景听感最好的就是大馒头 2 了，其他两个对杜比全景的还原效果并不好。

@echo1937
说是这么说，但是实际开发里很多场景这些 object 都可以一个搞定。

我自己的经验是，验证这种东西都尽量在 controller 层自己去手动判断，而不是借助于框架的 validation 。

因为框架验证需要传入借助很多注释 api，过于侵入 pojo 。有时候不止 api 层需要做 validation，orm 层也需要 validation，有时候一个 pojo 里有多种 validation 会很奇怪。而且许多的项目，虽然你在 controller 层禁止某个字段 NULL，但是实际上在数据库里存的是允许为 NULL，这样其他人看着就很困惑。

另外有时候多版本兼容、需求变更，可能某个接口里某个字段是允许为空的。这样的情况比比。

所以还是手动写比较好。

mysql 默认是 RR 级别。
对于读多得应用降一级成 RC 也是可以得。
RU 应该没人用吧。。？

没办法你只能比较。
举个例子就是，
前段时间去买一本 java 编程思想，jd 显示的是 68 元，后边刷新了一下页面就变成了 80 元。
没辙我就去淘宝买了，新华书店文轩网店，58 块钱入手。。。

而且这种平台还会根据你的使用习惯分析你是不是属于价格敏感一类的用户，然后再搞点事情。

苹果会不会在 wwdc 上发布新硬件难道不是取决于 9 10 两个月新发布硬件数多不多么。。。？

社会发展本来就是这样的啊。。。

你做任何一个行业都得考虑到随着科学技术发展你的位置会不会被新的机器给取代。

我的 2018 pro 11 寸也能拍出光晕效果。
这东西跟拍摄设备也有很大关系。

linux 给我的体验就是，单看桌面截图啥的可以觉得非常清新舒畅。
但是一上手就贼难受，各种 app 界面风格不一，字体显示效果和高分屏支持感人。

这次更新主要分无损和杜比全景声空间音频两块，跟 airpods 相关的是杜比全景声空间音频这块。
hifi 的话对你的设备可是有一定的要求的。

@huamiao
苹果自己沙盒机制，确保了就算使用了 xcodeghost 编译打包过的 app 也没办法做出什么出格的事情。

xcodeghost 向某个域名发送数据这种和其他各种统计工具类的 sdk 的表现并没有任何区别。

至于什么远程下发肉鸡命令一类的更是耸人听闻了。之前我看到过的一个 case 也只是模拟了 xcodeghost 下发一个网址，跳转打开以后提示你安装签名应用的。像这种东西吧，不需要任何 app，普通一个 app 服务端都能下发。

xcodeghost 在 ios 上的影响是真的有限。

@loniper sad 。苹果的苹果涂层脱落扩展维修计划并不包括 18 款，上回我去店里问过了。

iptables 是工作在网络层，怎么可能管的到应用层的 http 协议。
你需要一个应用层的防火墙

@Rwing 大部分的项目其实短平快方式效率更高。

设计模式、项目架构一类东西有时候过于工业化和笨重了。

特别是在国内，大部分互联网公司并不会太过于在意项目的可扩展性和维护性。为了跟进对手或者抢占市场都是以先实现功能为主，反正用的 java，代码写的再烂也能勉强调试维护下去。真的维护不动了就推翻重构或者重写。

如果项目竞争不过对手的话，这个项目可能还没到需要重写的地步可能就被关闭了。所以在国内的话，什么代码整洁、项目结构合理之类的东西并不能产生价值。

国外的话情况可能会不一样做项目就跟建房子一样，一步一步稳稳的来。像美帝那边的大厦都上百年了，国内的话可能三四十年就拆了重建吧。

在国内的互联网项目就不要考虑扩展性一类的东西了。没必要也没有意义。

国内的互联网项目很大的特点就是高层为了抢市场，经常会去起各种各样的项目养着，能养大的话就继续做，养不大就放弃掉。

一般这类项目能做大的话，后期如果撑不住的就直接推翻重构了。

请问如今输入法配合机器学习联想越来越智能的情况下，为什么你还要选择五笔？
五笔势必是要被时代淘汰的产物。
不是靠打字吃饭的，这个时候还学五笔怕只是想为了和别人不同吧？

@xiangyuecn 跟注解没关系。我不知道你的需求是什么才会想到这么膈应人的方法。我提供一个场景不知道符不符合你的需求。

某一个 Service 提供 findByName 方法，findByName 出于某种原因里边有个需求，如果没有查询到某个 Name，那么就创建一条这样的记录，也就是说 findByName 需要调用同 service 下的 create 方法。但是由于通过 this.create 方法，是没有走 spring 的事务增强的，那么很容易导致问题。那么你的解决思路是通过 Spring 的 AopUtils 来获取 this 在 spring 容器中增强过的 bean 。

你的这个想法的确是可以解决你的需求，但是这不是一个好的解决思路。

我更倾向于 findByName 和 create 方法在某一层进行聚合，而不是在 findByName 里调用 create 方法。或者你不想加入聚合层，你可以直接在 Sevice 创建一个新方法 findOrCreat()来聚合这两个 findByName 和 create 方法，然后你在 findOrCreat 上边打上 @Transactional 注释来控制内部嵌套事务的传播性，方便你更细粒度的处理事务提交和回滚。而且 findByName 能更好的专注于方法名所提供的功能，因为其他人去调用你的 findByName 时他们是不清楚你里边还有调用了 create 方法，玩意他们调用了然后创新了一条新纪录可能也不是他们自己的本意。

@xiangyuecn 解决的路子不对。
针对事务嵌套事务的处理，spring 有专门的事务传播机制可以选择。
可以在 @Transactional 注解里设置传播机制。