我个人的想法是两种实现思路
第一种 dao层你做方式二这样的，这样你在service通过session取到操作用户的id之后，在dao层操作数据库时加上作者id，给前端的接口是传文章id过来后端
第二种 dao层做方式一的，在service层取一下文章id对应的作者id，判断一下操作用户id和作者id是否相符，相符就调用dao层删除，不相符就返回错误，前端的接口一样还是传文章id过来

没注意你的注释哈
那么我再解释一下我的想法吧，我觉得你提的方式一比较好，首先在service做判断逻辑，Dao层专注于操作数据库，也方便把判断逻辑进行改写，同时还能返回错误操作的提示，如果你说方式二也能判断，也能抛异常告诉用户操作错误，只是把判断放在Dao层而已，那和我说的第二种也类似了，都是先取，再判断，再删，那不如把判断逻辑交给service层来做呢
当然如果删除操作可以返回被操作的数据条数，那也可以选择方式二嘛，如果操作了0条数据，那就代表文章不属于操作用户嘛，但是那样也很蛋疼，删除操作做完了才告诉你这篇文章不属于你、你不可以操作，想起来就怪怪的
一点点个人意见哈，不赞同的话可以继续讨论

个人感觉，

如果一篇博客对应一个作者的话，可以直接考虑方式二，
实现起来逻辑较简单，同时能减少数据库查询次数。

如果系统考虑到除作者之外还有其他管理员能对博客系统进行操作，考虑方式一，
这样扩展性好，当修改删除需求时较方便。

——一个没做过博客系统的人的猜想

防止其他作者通过修改id参数删除文章，需要在service中，先判断该文章是当前作者的

这个操作，无论如何传参，你都是要检查的。

那么问题就简单了，问题就变成了从session取authorId，还是从query string里面取authorId。

根据我用了多年的博客的经验。流行的博客程序是两个参数都从query string里面传递。但是，不是强制的。也就是你只传postId也是可以的。之所以这样做。是为了有更多的参数可以供自定义url格式使用。